toc

Team LiB
Next Section

Network Analysis, Architecture & Design, Second Edition
Network Analysis, Architecture & Design, Second Edition
by James D. McCabe ISBN:1558608877
Morgan Kaufmann Publishers © 2003 (450 pages)

This book works through the processes of analysis, architecture, and design step by step, giving network designers a solid resource for making good design decisions.

Table of Contents
 | Network Analysis, Architecture, and Design, Second Edition
 | Foreword
 | Preface
 | Chapter 1 | - | Introduction
 | Chapter 2 | - | Requirements Analysis: Concepts
 | Chapter 3 | - | Requirements Analysis: Process
 | Chapter 4 | - | Flow Analysis
 | Chapter 5 | - | Network Architecture
 | Chapter 6 | - | Addressing and Routing Architecture
 | Chapter 7 | - | Network Management Architecture
 | Chapter 8 | - | Performance Architecture
 | Chapter 9 | - | Security and Privacy Architecture
 | Chapter 10 | - | Selecting Technologies for the Network Design
 | Chapter 11 | - | Interconnecting Technologies Within the Network Design
 | Glossary of | - | Terms
 | Glossary of Acronyms
 | Index
 | List of Figures
 | List of Tables
 | List of Examples

Team LiB
Next Section


backcover

Team LiB

Back Cover

Network Analysis, Architecture, and Design, 2nd Edition, uses a systems methodology approach to teaching these concepts, which views the network (and the environment it impacts) as part of the larger system, looking at interactions and dependencies between the network and its users, applications, and devices. This approach matches the new business climate where customers drive the development of new services and the book discusses how networks can be architected and designed to provide many different types of services to customers.

This second edition contains an entirely new focus on network architecture, which completes the process from analysis to design. Network architecture takes the input from network analysis and provides a high-level view of the network, focusing on the relationships between major functions of the network, such as security, network management, performance and addressing and routing. A reference architecture, outlining how these functions are to be addressed within the network, serves as the foundation for the network design.

With a number of examples, analogies, instructor tips, and exercises, this book works through the processes of analysis, architecture, and design step by step, giving network designers a solid resource for making good design decisions.

About the Author

James D. McCabe is the network architect for BeamReach Networks. McCabe's interest in network analysis and design dates from the late 1980s, when he first worked on designs for NASA's aerospace supercomputing networks. Subsequent designs for various commercial, government and academic networks led him to develop and publish the processes described in this book, which he also teaches to students at various corporations and conferences. McCabe holds a degree in chemical engineering from the Georgia Institute of Technology.

Team LiB


Network Analysis, Architecture, and Design, Second Edition

James D. McCabe BeamReach Networks
MORGAN KAUFAMANN PUBLISHERS AN IMPRINT OF ELSEVIER SCIENCE
AMSTERDAM BOSTON LONDON NEW YORK OXFORD PARIS SAN DIEGO SAN FRANCISCO SINGAPORE SYDNEY TOKYO

Senior Editor
Rick Adams

Publishing Services Manager
Simon Crump

Project Manager
Kyle Sarofeen

Developmental Editor
Karyn Johnson

Project Management
Graphic World Publishing Services

Cover Design
Dick Hannus, Hannus Design Associates

Cover Image
PhotoDisc

Text Design
Frances Baca Design

Technical Illustration
Graphic World Illustration Studio

Composition
Graphic World Inc.

Copyeditor
Graphic World Publishing Services

Proofreader
Graphic World Publishing Services

Indexer
Graphic World Publishing Services

Cover Printer
Phoenix Color Corporation

Interior Printer
The Maple-Vail Book Manufacturing Group

Designations used by companies to distinguish their products are often claimed as trademarks or registered trademarks. In all instances in which Morgan Kaufmann Publishers is aware of a claim, the product names appear in initial capital or all capital letters. Readers, however, should contact the appropriate companies for more complete information regarding trademarks and registration.

340 Pine Street, Sixth Floor
San Francisco, CA 94104-3205
www.mkp.com

Copyright © 2003 by Elsevier Science (USA)

All rights reserved.

Printed in the United States of America

07 06 05 04 03 5 4 3 2 1

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means—electronic, mechanical, photocopying, or otherwise—without the prior written permission of the publisher.

A Catalog record for this book is available from the Library of Congress.

ISBN: 1-55860-887-7

This book is printed on acid-free paper.

Dedication

As I complete this book, it is but days after the destruction of Space Shuttle Columbia and I feel a deep sense of profound loss at this tragedy. I worked with Dr. Kalpana Chawla at the Numerical Aerodynamic Simulation (NAS) Facility at NASA Ames Research Center during the 1990s. I remember her pioneering spirit, great heart, warm smile, and brilliant mind. She was an inspiration to all of us at the NAS Facility and to many worldwide. This book is dedicated to her.


Foreword

In the 5 years since Jim McCabe published the first edition of this work, we witnessed a pace of growth in Internet communications and network deployment that some-how managed to outpace all the growth of the prior two decades. The epicenter of this growth is, of course, the Internet. But like many good things, "too much, too quickly" can prove to be a bad thing.

One only needs to consider recent Internet history to appreciate why. Connecting to the Internet became such a business imperative and came about so quickly that society embraced a new time measure, Internet time. Although there's nothing inherently bad about this per se, building networks in Internet time forced many organizations to deploy in haste and reaction mode. The result? Rather than networks designed to perform optimally, scale effectively, operate securely, and offer "five nines" availability, we have too many ad hoc networks, each lacking the characteristics of a well-conceived entity that can serve globally as a critical infrastructure.

Other factors contributed to the somewhat sorry state in which we find the Internet infrastructure mired. Recent technology advances—first switched then optical networking, broadband wireless communications, storage networking, and more— introduced as much chaos as innovation. Factor in the migration of private network backbones to virtual networks over a public Internet, the "always connected" mandate for today's mobile workforce, and application paradigms with decidedly different quality-of-service metrics than those for which "best-effort delivery" networks were originally intended to support, and it's no wonder we are where we are today.

How appropriate that someone like Jim McCabe, who's experienced and contributed so much to the transformation of the Internet—from its research and military origins to its current status as a global, multiservices infrastructure—is sharing his collected wisdom, experience, and expertise to help us take measure and apply the sound principles of network analysis, architecture, and design to Internet working today. And how timely.

We are at a unique and unexpected moment in Internet history. A desultory economy has slowed the pace of innovation, spending, and hence network deployment. Harried network administrators and planners are quietly breathing a collective sigh of relief. The most astute of this bunch recognize that such reprieves come rarely in a network deployment life cycle. With the insight garnered from years of building complex, state-of-the-art Internets, Jim McCabe's Network Analysis, Architecture, and Design provides a timely, comprehensive methodology that will prove invaluable to anyone saddled with new network deployment, or reengineering of a network that grew "organically" and is now out of control.

My first edition is dog-eared, highlighted, and annotated to the point where certain pages are unreadable. The spine is broken as a result of stuffing altogether too many sheets of paper with notes and network designs I developed using Jim's methodology.

After my first read of the second edition, I have no expectation that this copy will look any better for wear 5 years hence.

—David M. Piscitello, Core Competence Inc.


Preface

Network Analysis, Architecture, and Design, second edition, is about understanding how networks function and behave in supporting the requirements of users, applications, devices, and traffic flows and how to use this information to build the architectural and design foundations for your network.

Since the writing of the first edition, Practical Computer Network Analysis and Design, a number of concepts introduced in that book have been growing in popularity among network professionals. Traffic flow analysis and the coupling of performance requirements to traffic flows is becoming increasingly important in providing quality of service and differentiating between services within the network. Gathering and analyzing requirements to formally prepare for the network design is now widely recognized as essential to ensure accuracy and consistency within the design. The systems approach, where the network is a resource of a system consisting of users, applications, and devices, is now the model being used to build large-scale computing and communications networks (including grid networks). The processes introduced in that book for analysis and design have been adopted by corporations, universities, and government agencies around the world.

Network Analysis, Architecture, and Design, second edition, expands on these innovative, yet fundamental, concepts and adds a new dimension—network architecture—to the process. Network architecture complements analysis and design, determining the relationships between major functions of the network—security, management, performance, and addressing and routing—upon which the design is based. I have found that adding network architecture to the analysis and design processes has significantly improved the resulting designs by considering security, management, performance, and addressing and routing earlier in the process.

Approach

Network Analysis, Architecture, and Design, second edition, will help you understand and define your network architecture and design. It examines the entire system, from users and their applications, to the devices and networks that support them.

This book was designed to be used in undergraduate and graduate programs in network engineering, architecture, and design, as well as for professional study. It is structured to follow the logical progression of analyzing requirements, which flow into the network architecture, which forms the basis for the network design. When I teach network analysis, architecture, and design at universities, corporations, and conferences, I find that the material in this book is readily adapted by students' as part of their engineering process.

In this book, I provide you with step-by-step procedures for doing network analysis, architecture, and design. I have refined this process through years of architecting and designing large-scale networks for government agencies, universities, and corporations, and I have incorporated the ideas and experiences of expert designers throughout the book. Like an open standard for a technology or protocol, the procedures in this book are the result of several contributions and offer you the cumulative experience of many network architects and designers.

I tackle some of the hard problems in network analysis, architecture, and design and address real architecture and design challenges, including how to:

  • Gather, derive, and define real requirements for your network

  • Determine how and where addressing and routing, security, network management, and performance are implemented in the network

  • Evaluate and choose network technologies, such as Fast/Gigabit/10G Ethernet, SONET, POS, and others, for your network

  • Evaluate and choose mechanisms to interconnect these technologies, such as switching, routing, and flow-based mechanisms

  • Determine where to apply routing protocols (RIP/RIPv2, OSPF, BGPv4, MPLS), as well as classful and classless IP addressing mechanisms

  • Determine where to apply performance mechanisms, including quality of service, service-level agreements, and policies in your network

In addressing challenges such as these, I provide guidelines, examples, and general principles to help you in making the tough decisions. You may find some or all of them to be useful, and I encourage you to modify them to fit your architecture and design needs.

For those using this book in a class or for self-study, each chapter concludes with a number of exercises. In addition, the Web page for this book at the publisher's web site ( www.mkp.com ) contains additional material useful in your progress through the book, as well as a password-protected solutions manual to the exercises available to instructors.


Roadmap

The first four chapters are based on the systems approach, requirements analysis, and flow analysis from the first edition. They have been updated to include changes and improvements in network analysis since the release of the first edition. Chapter 1 introduces network analysis, including the systems approach, and provides definitions and concepts that will be used throughout the book. Chapters 2 and 3 focus on the concepts and process of determining requirements for your network, and Chapter 4 discusses how traffic flow analysis can be used to couple performance requirements to various traffic flows.

Chapters 5 through 9 are new for this edition, covering the network architecture process. Chapter 5 provides an introduction to network architecture, developing internal and external relationships within and between major functions (addressing and routing, security, network management, and performance) in the network. Chapters 6 through 9 detail each of these major functions, developing component and reference architectures that describe their internal and external relationships.

Chapters 10 and 11 are not significantly different from their network design counterparts in the first edition. Chapter 10 discusses how to decide which technologies are optimal for your network, including developing technology evaluation criteria and using the results of network analysis and architecture. Chapter 11 complements Chapter 10, detailing how network technologies can be interconnected, including switching, routing, and flow-based mechanisms.

At the beginning of each chapter, I have provided a list of recommended reading that will be useful to you in understanding the concepts of that chapter. This book introduces a fair number of new concepts, so I also provide an extensive glossary of acronyms and terms that are used throughout the book.


Acknowledgments

The material presented in this book is based on a compilation of my own practical experiences and those of other members of the networking community. As always, I am solely responsible for any errors in this book. Network analysis, architecture, and design are constantly evolving, and any feedback on how to improve these processes is most welcome. Questions, comments, and suggestions can be sent to me at <doowah@doowah.com> or through Morgan Kaufmann Publishing.

I owe a great deal of thanks to people who reviewed all or part of this book. Dr. Hongwei Du, California State University, Hayward; Robert Hudyma, Ryerson University; Mike Little, NASA; and Norman Patty, BellSouth.

The people at Morgan Kaufmann Publishing have been a wonderful influence on the development of this edition. Many thanks to Dr. David Clark, Series Editor, and to Rick Adams, Karyn Johnson, and Cheri Palmer. I would also like to thank my production editor, Suzanne Kastner, for her patience and understanding throughout.

I also want to thank others who have helped in the development of this book. First, many thanks to Mike Little of NASA Langley Research Center for his insight and direct input to several chapters in this book. In particular, Mike provided a significant amount of new material for the requirements analysis process and has developed a case study that will provided on the Web site.

Thanks also to Eric Garcia at BeamReach Networks for his understanding and help through this long and arduous process. Whether it is tossing around ideas, letting me lean on him for advice, or taking on the burden at BeamReach, Eric has been a tremendous help. Thanks also to Chris Keller and the rest of the Systems Development Group at BeamReach for helping me select the cover for this book, always a trying process.

The chapters on requirements and flow analyses are based on early work on data flow analysis done at the Numerical Aerodynamic Simulation (NAS) facility at NASA Ames Research Center. I owe much thanks to Bruce Blaylock of Cisco Systems, who had the foresight to encourage this work, as well as the tenacity to help see me through the process.

Others who have been instrumental in the development of this book include Kevin Brown, Pierre Catala, Dr. Pisit Charnkeitkong, Alan Mehlenbacher, Mike Minnich, and Keith Nesson.


Chapter 1: Introduction

We begin this book with an introduction to the analysis, architecture, and design processes. Many concepts and terms that are used throughout this book are introduced and defined in this chapter. Some of these concepts may be new to you while others are presented in a different light. Glossaries of terms and acronyms are provided at the end of this book for easy reference.

1.1 Objectives

The objectives of this chapter are to:

  1. Introduce the fundamental concepts of this book; the processes of network analysis, architecture, and design; systems and services; as well as their characteristics

  2. Define several terms used throughout the book

  3. Prepare the reader for the analysis process


1.2 Preparation

To be able to understand and apply the concepts in this chapter, you should be familiar with basic networking concepts, including functions and features of the TCP/IP protocol suite; technologies such as Ethernet, Fast Ethernet, Gigabit Ethernet, asynchronous transfer mode (ATM), synchronous optical network (SONET), and frame relay; and the basics of network performance. Some recommended sources of information include:

  • TCP/IP Illustrated, volume 1, by W. Richard Stevens, Addison-Wesley Publishing, January 1994

  • Essentials of ATM Networks and Services, by Oliver Chukwudi Ibe, Addison-Wesley Publishing, January 1997

  • ATM and SONET Basics, by George Dobrowski and Donald Grise, APDG Publishing, January 2001

  • Switched, Fast, and Gigabit Ethernet, by Sean Riley and Robert A. Breyer, New Riders Publishing, January 1999

  • Frame Relay: Technology and Practice, by Jeff T. Buckwalter, Addison-Wesley Publishing, December 1999


1.3 Background

Network analysis, architecture, and design have traditionally been considered art, combining an individual's particular rules on evaluating and choosing network technologies; knowledge about how technologies, services, and protocols can be meaningfully combined; experience in what works and what doesn't; along with (often arbitrary) selections of network architectures. However, as in other types of art, success of a particular network architecture or design often depends primarily on who is doing the work, with results that are rarely reproducible. This may have been acceptable in the early days of networking, when networks were more of a hobby than a critical resource and did not support revenue generation. Today, however, networks are embedded within our work and home lives. They are considered "mission-critical" to corporate success and provide near real-time access to information throughout the world. As such, a network's architecture and design must be logical, reproducible, and defensible. This premise is the foundation for this book.

Traditionally, network analysis, architecture, and design have been based on developing and applying a set of rules for the network. In developing a set of rules, an individual may draw from experience or from general rules such as the 80/20 rule (where 80% of a network's traffic is local, and 20% is remote) or the adage "bridge when you can, route when you must" (bridging being simpler, easier, and cheaper at the time). Both of these rules have been modified, as we will see later in the book. Such rules were useful when there weren't many choices in network technologies, services, and interconnection strategies and when the differences between choices were clearly understood. But times have changed, and our notion of architecting and designing networks must adapt to the variety of options now available to us, the many different types of services we can offer to our end customers (users), and the subtleties between technologies.

Network analysis, architecture, and design have traditionally focused on capacity planning, which is estimating capacity (also known as bandwidth) required in the network to accommodate most short-and long-term traffic fluctuations. As network traffic grows, this bandwidth "buffer" provided by capacity planning reduces and customers experience problems related to congestion. Some common solutions are to "throw bandwidth at the problem," increasing the bandwidth buffer to (hopefully) reduce congestion, or to overengineer the network, intentionally adding capacity to accommodate network fluctuations. This approach often does not work, as network bandwidth is only one component of network resources that must be considered. We now also need to consider how delay performance can be optimized. And, in many cases, network reliability, maintainability, and availability, also known as RMA (more on this in Section 1.9), are more important than overall throughput.

In this book we will explore how the analysis, architecture, and design processes have changed and how they continue to change. We will discuss how these processes work together in engineering a new or existing network. We will approach networks from a different perspective—as a system providing services to customers—and we discuss how networks can be architected and designed to provide many different types of services to its customers (users). In taking this approach, we will emphasize network analysis, which helps us understand what will be required of a network in supporting its customers and their applications and devices. As we will see, these processes require an investment of time and effort, but the return on investment is significant. They are powerful tools that can help you build better networks.

This book begins by applying a systems methodology to networking. This methodology is relatively new, and you will learn a number of useful definitions for network analysis, architecture, and design. The rest of the book is logically divided into three sections. The first section covers the analysis process, consisting of how to develop requirements, flow, and risk analyses. The analysis process prepares you for network architecture and design, discussed in the following two sections. The second section discusses how to understand the relationships between functions within your network and how to develop an architecture describing these relationships. In the final section the network architecture is used as input for the network design process, where technology selection and connectivity are determined. The information flows between network analysis, architecture, and design are presented in Figure 1.1.

Click To expand
Figure 1.1: Information flows between network analysis, architecture, and design.

Network analysis, architecture, and design will help you identify and apply the services and performance levels that your network must satisfy. Through these processes, you will be able to architect and design your network to provide the desired services and performance levels and will be able to choose the appropriate network technologies and interconnection strategies to meet your architectural and design goals.


1.4 Overview of Analysis, Architecture, and Design Processes

What are network analysis, architecture, and design? Network analysis is about studying network components (from network devices such as switches and routers, to requirements and performance levels) and their inputs and outputs to understand network behavior under various situations (Figure 1.2). Network analysis defines, determines, and describes relationships between network components for many conditions. In analyzing a network, we will examine the state of the existing network, including whatever problems it is having. We will also examine network goals and requirements, traffic flows, and user and application behavior. Analysis results include descriptions of requirements and traffic flows, as well as mappings of users, applications, and devices within the network environment (everything that is external to the network, for example, users, applications, devices, buildings, business environment).

Click To expand
Figure 1.2: Inputs and outputs to network analysis process.

Network analysis helps us understand what problems we are trying to solve, and in the process, we compile information that will be used in developing an architecture and design.

Network architecture uses this information to develop a high-level, end-to-end structure for the network. A network architecture develops the major network functions (e.g., addressing/routing, network management, performance, security) as architectural components that will be brought together to form the network; goals for the architecture; and sets of interactions, trade-offs, dependencies, and constraints (these will be described in detail later) that will be used to optimize the architecture. There usually is not a single "right" architecture or design for a network; instead there are several that will work, some better than others. Architecture and design focus on finding the best network (optimized across several parameters) for your customer. Network architecture also provides a set of guidelines that can be used to formulate the technical design of a network.

Results of the network architecture process include a reference network architecture (or just reference architecture), which is a description of the complete network, considering all of its architectural components. It is a compilation of the relationships developed during the network architecture process. Results also include descriptions of the interactions, trade-offs, dependencies, and constraints used to arrive at that architecture.

Click To expand
Figure 1.3: Inputs and outputs to network architecture process.

Network design provides physical detail to the reference architecture. During network design, you evaluate and choose technologies for each area of the network and develop strategies to connect these technologies across the network. You will learn how to set design goals, such as minimizing network costs or maximizing performance, as well as how to achieve these goals, through mapping network performance and function to your design goals and evaluating your design against its goals to recognize when the design varies significantly from these goals. Network design is also about applying the trade-offs, dependencies, and constraints developed as part of the network architecture. Trade-offs, such as cost versus performance or simplicity versus function, occur throughout the design process, and a large part of network design concerns recognizing such trade-offs (as well as interactions, dependencies, and constraints) and optimizing the design between them. As part of the design process, you will also learn how to develop evaluation criteria for your designs.

As we will see throughout the remainder of this book, network analysis, architecture, and design combine several things—requirements, traffic flows, architectural and design goals, interactions, trade-offs, dependencies, constraints, and evaluation criteria—to optimize a network's architecture and design across several parameters. These parameters are chosen and analyzed during the analysis process and prioritized and evaluated during the architecture and design processes. Upon completion of these processes, you should have a thorough understanding of the network and plenty of documentation to take you forward to implementation, testing, and integration.

Example 1.1
Start example

A network's architecture and design are analogous to the architecture and design of a home. Both the network and home architecture describe the major functional components of each (for the network, network management, addressing and routing, security and privacy, and performance; for the home, plumbing, electrical, HVAC [heating, vacuum, air conditioning], framing) and the relationships between them (for the network, interactions, dependencies, trade-offs, and constraints; for the home, where each component is placed relative to one another). The network and home designs are also similar in that they both provide physical detail to the architecture. For the network, this means where major network devices are located and, for the home, where ducts, outlets, faucets, drains, and so forth are located.

End example

1.4.1 Hierarchy and Interconnectivity

All of these processes center around two important characteristics of networks: their levels of hierarchy and interconnectivity. Hierarchy is the degree of concentration of networks or traffic flows at interconnection points within the network, as well as the number of tiers of interconnection points within the network. In general, as networks grow in size and numbers of users, applications, and devices increase, hierarchies provide separation and structure within the network. Hierarchies are important because they help us in determining the sizes of networks, including routing and addressing configurations, and the scaling of network technologies, performance, and service levels. A key concept of this book is understanding these hierarchies, learning how and where they will occur, and learning how to take advantage of them.

Along with hierarchy, there must be some consideration for the degree of interconnectivity (or redundancy) in the network design. As hierarchy provides structure in the network, interconnectivity balances this structure by interconnecting the network at different levels in the design to provide greater performance through parts of the network. Interconnectivity is important in that it provides a mechanism to achieve performance within a hierarchical structure. The dynamic between hierarchy and interconnectivity is perhaps one of the most fundamental trade-offs in network architecture and design, and it shows up several times in the analysis, architecture, and design processes.

Hierarchy and interconnectivity may be a bit confusing at this point, but they will become clearer as we progress through the book. Hierarchy is fundamental to networking (as it is throughout nature): It provides a separation of the network into segments. These segments may be separate, smaller networks, or subnets, or broadcast domains. This is necessary when the amount of traffic on the network grows beyond the capacity of the network or when interactions between devices on the network result in congestion (e.g., broadcast storms).

Figure 1.4 illustrates levels of hierarchy and interconnectivity in a network. This is a typical tree structure for a network, with circles representing networks or routers and lines representing the communications links between networks and/or routers. In this figure there are four levels of hierarchy, from core (or backbone) networks to access networks closest to users. Note that the end points of this tree (commonly refereed to as leaves; they represent the end networks, devices, or users) all occur at the same level of hierarchy. This does not have to be the case; indeed, in most networks there are leaves at most levels of hierarchy.

Click To expand
Figure 1.4: Hierarchy and interconnectivity in a network.

An example of adding hierarchy to a network is changing from a flat (bridged or layer 2 switched) structure to a routed structure. This may be done to reduce the size of the broadcast domain or the number of devices that are reached by a broadcast message. Adding routing to the network breaks a broadcast domain into a number of smaller broadcast domains, and traffic flows are concentrated at routers. Figure 1.5 shows this scenario.

Click To expand
Figure 1.5: Hierarchy added to a network.

A content delivery network (CDN) is an example of adding interconnectivity to a network. A CDN bypasses the core of a network, where congestion is most likely to occur, and directly connects devices or networks lower in the hierarchy (Figure 1.6). This provides better, more predictable performance but can also affect the network hierarchy by modifying its routing behavior.

Click To expand
Figure 1.6: Interconnectivity added to a network.

1.4.2 Importance of Network Analysis

The importance of network analysis is emphasized in this book because experience has shown that networking personnel find it extremely valuable—once they are convinced of its importance. Analysis takes work, and when you know that there will be a payoff, you will be more likely to do that work.

In this book you will learn how to gather and analyze network requirements and traffic flows. Network requirements are requests for capabilities in the network, usually in terms of performance and function, which are necessary for the success of that network. Network requirements can be gathered and/or derived from customers, applications, and devices. Such requirements are fundamental to a network's architecture and design—they form the basis for customer expectations and satisfaction. Requirements, in conjunction with measurements on the existing network (if there is one), are used to derive traffic flows (sets of network traffic that have some common attributes, such as source/destination address, information type, routing, or other end-to-end information). Analysis of these flows imparts location and directional information onto requirements. This is where performance requirements and architecture start to converge and is often the point in these processes where one can begin to see where "hot spots"—focal points for network performance—will appear in the network. As we will see, evaluating security risks is also part of the analysis process.

Results of the analysis process, the requirements and flow specifications, are then used as input for both network architecture and design. In developing the network architecture, a number of component architectures, targeting particular functions of the network, will be evaluated. Desired component architectures will then be combined into the reference architecture, which will provide a high-level view of your network. This high-level view is then physically detailed during the network design process.

Network analysis is important in that it helps us understand the complexity and nuances of each network and the systems they support. Analysis also provides data upon which various decisions are made, and these data can and should be documented as part of an audit trail for the architecture and design processes. Such data help ensure that the resulting architecture and design are defensible.

Understanding Network and System Complexity

In general, networks and the systems that they support are becoming increasingly complex. Part of this complexity lies in the sophistication of the capabilities provided by that network. Consider, for example, how services can be incorporated into a current state-of-the-art network. Infrastructure capacity planning, which often includes traffic overengineering, may now be expanded to include support for delay-constrained applications and may contain a variety of capacity and delay control mechanisms, such as traffic shaping, quality of service at multiple levels in the network, service-level agreements to couple services to customers, and policies to govern and implement service throughout the network. (Note that quality of service refers to determining, setting, and acting on priority levels for traffic flows. A service-level agreement is an informal or formal contract between a provider and user that defines the terms of the provider's responsibility to the user and the type and extent of accountability if those responsibilities are not met. Finally, policies are high-level statements about how network resources are to be allocated among users.) Analysis of these mechanisms— how they work and interoperate—will be covered in detail later in this book.

Network and system complexity is nonlinear. Network optimization must consider competing and often conflicting needs. In addition, multiple groups with differing ideas and desires (e.g., users, corporate management, network staff) influence the network design. The network is either designed by committee or through a systematic approach that the groups can agree on.

Networks have evolved to incorporate more sophisticated capabilities. Early (first-generation) networks focused on supporting basic connectivity between devices and on how to scale networks to support growing numbers of users (e.g., segmenting networks using bridges or routers). Second-generation networks focused on interoperability to expand the scope and scale of networks to allow connections between multiple disparate networks. We are currently at the stage in network evolution where service delivery is important to the success of users and their applications. This is the generation of network services, which can be considered the third generation of networking. Figure 1.7 illustrates the various generations of networking and their interactions.

Click To expand
Figure 1.7: Generations of networking.

We are beginning to see steps toward next-generation capabilities, such as rudimentary decision making within the network. It may be expected that components of the network will evolve to become self-configurable and manageable, especially for those networks that must be configured or administered by end users (e.g., telecommuters, users of mobility/portability services). Indeed, this will become necessary as the complexity and performance of networks increase and as services offered by networks become more sophisticated.

Along with networks, users, applications, and devices are also evolving more sophisticated capabilities. An example of this is the dynamic between hierarchy and interconnectivity as can be seen in the current Internet. As application and device traffic flows evolve to incorporate information regarding quality, performance, and cost (e.g., real-time streaming media), it is expected that these characteristics can be used to ensure paths through the Internet that will support high performance or high-quality delivery of such traffic. Hierarchy in the Internet often forces traffic flows through nonoptimal paths, hindering high-performance, high-quality delivery. Figure 1.8 shows a hierarchy of multiple levels of networks from core (or backbone) network providers to access network providers. Traffic flows between end users may travel across several levels of this hierarchy.

Click To expand
Figure 1.8: Hierarchy and traffic flow.

To counteract the impact of hierarchy, interconnectivity can be introduced into the Internet at strategic points, providing shortcuts that bypass parts of the Internet. The result is that, for some select flows, paths are optimized for high-performance, high-quality delivery (Figure 1.9). The dynamic between hierarchy and interconnectivity exists in all networks to some degree, and part of the analysis process is determining where and how to apply it. In Figure 1.9, connections are added between networks at the same level of hierarchy, in essence providing a "shortcut" or "bypass" around part of the Internet, resulting in better performance characteristics.

Click To expand
Figure 1.9: Interconnectivity added to optimize traffic flow.

Analysis helps us understand how technologies influence networks, users, applications, and devices (and vice versa). This is important in understanding how users of the network will adapt to the network, which affects the overall life cycle of the network. Consider, for example, the evolution of routing protocols, shown in Figure 1.10. Although the Routing Information Protocol (RIP), an Interior Gateway Protocol (IGP) deployed as part of early TCP/IP releases, was simple and easy to use, its limitations were stressed as networks expanded to accommodate larger groups of users (workgroups), even groups of networks (autonomous system [AS]). Routing technology adapted by adding hierarchy to routing, in terms of new IGPs such as Open Shortest Path First (OSPF), as well as in development of Exterior Gateway Protocols (EGPs) such as Border Gateway Protocol (BGP), which can accommodate hierarchy in groups of networks (AS hierarchy). This process continues today as high-level policies are being introduced to control routing at a level above IGPs or EGPs, and BGP4 introduces hierarchy through grouping BGP4 routers into confederations. We will discuss routing protocols in detail in the addressing and routing architecture (see Chapter 6).

Click To expand
Figure 1.10: Routing evolution.

Similarly, users, applications, and devices also influence their environment. As new, upgraded, or different users, applications, and devices are added to a network, the requirements on that network may change. The analysis process should examine how the impact of high-end compute and applications servers, data storage, analysis and archival systems, and specialized environment-specific devices such as video cameras or medical equipment changes the network.

Finally, the analysis process helps us understand the forces and changes at work within the system (network and its users, applications, and devices). Networks are highly dynamic, changing the rest of the system and being changed by the system. Some of the factors leading to change in the system include usage behavior and patterns; what, how, where, and when each user impacts the system; the emergence of new capabilities, for example, optical switching, faster central processing units (CPUs) and cheaper memory; and changes in scope and scale of the environment, including consolidation and outsourcing.

Architecture and Design Defensibility

An important (and often overlooked) part of network analysis is that, when documented properly, analysis should provide information about decision making in the network architecture and design processes. During the analysis process, we are gathering data that can be used to determine which architectural and design decisions need to be made, details regarding each decision (including reasons for each decision), dependencies between decisions, and any background material used to arrive at these decisions.

Data from network analysis, along with any decisions made during the process, can be documented to form an audit trail, that is, the set of documents, data, and decisions, for the architecture and design. Audit trails are useful in describing and defending a particular network architecture or design. An audit trail helps address questions such as "Why did you choose that technology?" "Why doesn't this new network perform as expected?" or "Why did this network cost so much?" Having documented your analysis of the existing network, the problems to be addressed, requirements for the new network, and all decisions made regarding that network, you will be able to answer questions at any time about your new network.

Decisions made regarding the network architecture and design need to be defensible from several perspectives: budgetary, to ensure that network costs are within budget or to provide good reason why a budget has been exceeded; schedule, to ensure that time frames for development, installation, testing, and operations are being met; and resources, such as personnel or equipment, to ensure that the customer has everything necessary to build and operate this network.

An audit trail is also useful as a historical document about the network. Over time, after the network is made operational, new network personnel can review this document to understand the logic behind the way that network was designed. Ideally, this document should be periodically reviewed, with new information added regarding changes to the network. Thus, an audit trail becomes a history for that network.

Experience shows that the set of documents, data, and decisions in an audit trail can be vital in making day-to-day tactical design decisions throughout the project. The investment in time at this phase of the project can save large amounts of time and resources later in the project.

The Web is a great tool to use in building an audit trail. Since an audit trail contains information about the old network, the new network, and decisions made about the new network, having this information easily accessible by those who use the network makes a lot of sense. Putting such information on internal Web pages allows easy access by everyone, and changes or additions to the audit trail can be seen immediately. Although there may be some information that your customer might not want everyone to view, such as the results of a risk analysis, most information usually can be accessible to everyone. For information that is restricted (need-to-know), hidden and password-protected Web pages can be used. Of course, when putting sensitive information at a common location, such as a Web site, sufficient security from outside attacks (hackers) should be provided.

An audit trail can be developed using standard word processing and spreadsheet software tools, and software tools specialized for this purpose are available. Requirements, problem definitions, goals, decisions, and all background data are entered into the audit trail, and all information is time-stamped. Examples of audit trail information are presented later in this book.

1.4.3 Model for Network Analysis, Architecture, and Design

Networking traditionally has had little or no basis in analysis or architectural development, with designers often either relying on technologies that they are most familiar with or those that are new or popular or being influenced by vendors and/or consultants. There are serious problems with this traditional approach, particularly that decisions may be made without the due diligence of analysis or architectural development and that such decisions made during the early phases of the project are uninformed.

As a result, there may not be an audit trail for the architecture and design; therefore, the architecture and design are not defensible. In addition, such an architecture/design may lack consistency in its technological approach. Lacking data from analysis and architecture, we may not have a basis for making technology comparisons and trade-offs. Therefore, network analysis, architecture, and design are fundamental to the development of a network.

Network analysis, architecture, and design are similar to other development processes in that they address the following areas:

  • Defining the problems to be addressed

  • Establishing and managing customer expectations

  • Monitoring the existing network, system, and its environment

  • Analyzing data

  • Developing a set of options to solve problems

  • Evaluating and optimizing options based on various trade-offs

  • Selecting one or more options

  • Planning the implementation

In defining the problems to be addressed, this should be a quick evaluation of the environment and project, in essence performing a sanity check on the task at hand, as well as determining the size and scope of the problems, determining that you are working on the right problems, and checking the levels of difficulty anticipated in the technologies, potential architectures and designs, administration, management, and politics in that environment. As you size up the problems faced in this project, you should begin to estimate the level of resources needed (e.g., budget, schedule, personnel). You should also develop your own view of the problems affecting that environment. You may find that, from your analysis of the situation, your definition of the problems may differ from the customer's definition. Depending on how far apart your definitions are, you may need to adjust your customer's expectations about the project.

Example 1.2
Start example

Once, in performing an analysis on a customer's metropolitan-area network (MAN), I realized that the problem was not what the customer thought—that the technology chosen at that time, switched multimegabit data service (SMDS), and the routing protocol (OSPF) were not working properly together. Rather the problem was that the network personnel had forgotten to connect any of their LANs to the MAN. Of course, when they ran tests from one LAN to another, no data were being passed. It was an easy problem to fix, but a lot of work was spent changing the customer's view on the problem and expectations of what needed to be done. The customer originally wanted to change vendors for the routing equipment and replace the SMDS service. Eventually, the customer was convinced that the equipment and service were fine and that the problem was internal to the organization.

Although SMDS is not widely available anymore, its behavior as a nonbroadcast multipleaccess (NBMA) technology is similar to other currently available technologies such as ATM and frame relay.

End example

An early part of every project is determining what your customer's expectations are about the project and adjusting these expectations accordingly. The idea here is not to give customers false expectations or to let them have unrealistic expectations; this will only lead to difficulties later in the project. Instead, the goal is to provide an accurate and realistic view of the technical problems in the network and what it will take to solve them. Customers' expectations will likely focus on budget, schedule, and personnel but may also include their opinions about technologies and methodologies. And, at times, politics become imbedded within the project and must be dealt with. The key here is to separate technical from nontechnical issues and focus on technical and resource issues.

Part of determining customers' expectations is understanding what customers want to do with their network. This may involve understanding the customer's business model and operations. In addition, the customer may expect to have significant input into the development of the network. As you set the customer's expectations, you may need to establish the lines of communication between the network architecture/design group, management, users, and network staff.

Having established what the customer's expectations are, you may need to adjust and manage these expectations. This can be done by identifying trade-offs and options for resources, technologies, architectures, and designs and then presenting and discussing trade-offs and options with your customer. Bringing customers into the process and working with them to make critical decisions about the network will help them become comfortable with the process.

If an existing network is part of this project, monitoring this network, as well as other parts of the system and its environment, can provide valuable information about the current behavior of users, applications, and devices and their requirements for the new network. Monitoring can also validate your and your customer's definitions of the problems with the existing network. When it is possible to monitor the network, you will need to determine what data you want to collect (based on what you want to accomplish with the data), any strategic places in the network where you want to collect this data, and the frequency and duration of data collection.

At this point in the process you should have several sets of information with which you can begin your network analysis. You may have historical data from network management; data captured during monitoring; requirements gathered from users, staff, and management; the customer's definition of the problem; and your definition. All of these data are used in the network analysis, of which there are three parts: requirements or needs analysis, flow analysis, and a risk (security) analysis. Information in these analyses can be placed on the customer's internal Web page, as mentioned earlier, although some information (e.g., the results of the risk analysis) may need to be kept private.

Results of the network analysis are used in the architecture and design processes, where sets of options are developed, including potential architectures, designs, topologies, technologies, hardware, software, protocols, and services.

These sets of options are then evaluated to determine the optimal solutions for the problems. Criteria will need to be developed throughout the analysis, architecture, and design processes in order to evaluate these options. Along with these criteria, you will use the results of the network analysis, including requirements, trade-offs, and dependencies between options.

Having selected one or more options, you will able to complete the network architecture and design and prepare for implementation. At this point you may consider developing a project plan to determine schedule, budget, and resources, as well as major and minor milestones, checkpoints, and reviews.


1.5 A Systems Methodology

We begin the network analysis process with a discussion about the systems methodology approach to networking. Applying a systems methodology to network analysis, architecture, and design is a relatively new approach, particularly in the Internet Protocol (IP) world. Systems methodology (as applied to networking) is viewing the network that you are architecting and designing, along with a subset of its environment (everything that the network interacts with or impacts), as a system. Associated with this system are sets of services (levels of performance and function) that are offered by the network to the rest of the system. This approach considers the network as part of the larger system, looking at interactions and dependencies between the network and its users, applications, and devices. As you will see, the systems methodology reveals interesting concepts that will be used throughout this book.

One of the fundamental concepts of the systems methodology is that network architectures and designs take into account the services that each network will provide and support. This reflects the growing sophistication of networks, which have evolved from providing basic connectivity and packet-forwarding performance to being a platform for various services. As discussed earlier, we are currently at the stage in network evolution where services are important to the success of many networks (third-generation networks). Some examples of third-generation networks are service-provider networks that support multiple levels of performance and pricing to its customers, contentdistribution networks that specialize in high performance transport, and enterprise networks that incorporate and apply billing and usage models to their customers.

When a network is viewed as part of a system that provides services, the systems methodology works quite well for a variety of networks, from small and simple to large, complex networks. It helps in determining, defining, and describing the important characteristics and capabilities of your network.


1.6 System Description

A system is a set of components that work together to support or provide connectivity, communications, and services to users of the system. Generically speaking, components of the system include users, applications, devices, and networks. Although users of the system can be considered outside of the system, they also have requirements that include them as part of the system. Throughout this book we will include users as part of the system. Figure 1.11 shows how these components are connected within the system.

Click To expand
Figure 1.11: Generic components of a system.

Figure 1.11 shows the generic components of a system. These components can be subdivided, if necessary, to focus on a particular part of the system. For example, users in a corporate network could be further described as network and computer support personnel, as well as developers and customers of that corporation's product. In a similar sense, applications may be specific to a particular user, customer or group, generic to a customer base, or generic across the entire network.

If we were to compare this view of a system with the open system interconnect (OSI) protocol model, it would look like Figure 1.12. Note that in this comparison, some of the OSI layers are modified. This is to show that there may be multiple protocol layers operating at one of the system levels. For example, the OSI physical, data link, and network layers may be present at the device level and may also be present multiple times at the network level (e.g., at switches and routers throughout the network).

Click To expand
Figure 1.12: Comparison of OSI layers to system levels.

Figure 1.13 shows that devices can be subdivided by class to show specialized functions, such as storage, compute, or application servers, or an individual device may be subdivided to show its operating system (OS), device drivers, peripheral hardware, or application programming interface (API).

Click To expand
Figure 1.13: Device component separated into constituents.

All of these components work together to provide connectivity and communications across the network, between users, applications, and devices. The connectivity and communications can be tailored to meet the specific needs of users and applications, such as real-time delivery of voice or streaming media, best-effort delivery of noninteractive data, or reliable delivery of mission-critical data.

The degree of granularity used to describe system components is a trade-off between the amount of detail and accuracy you want in the description and how much time and effort you are willing to put into it. If you are the network architect responsible for a corporate network, you may have the ability to invest time and resources into developing a detailed description of your system's components, whereas a consultant or vendor's design engineer may have little time and resources to spend on such a description. It is important to note, however, that even a small amount of time invested here will pay dividends later in the analysis process.

The traditional view of a system focused on the network providing connectivity between devices (Figure 1.14) and typically did not consider the users or applications.

Click To expand
Figure 1.14: Traditional view of system.

This traditional view of a system is not complete enough for today's networks. In particular, we need to include users and their applications in the system description. Experience shows that the degree of descriptiveness in the set (users, applications, devices, and networks) is usually sufficient to provide a complete and accurate description of most general-access systems, yet not so large as to be overwhelming to the network architect. (General-access is a term to describe common access of users to applications, computing, and storage resources across a network.) Within this set, users represent the end users, or customers, of the system. These end users are the final recipients of the network services supported by the system.

One reason for identifying components of the system is to understand how these components interface with each other across component boundaries. By defining what the components of the system are, we are also setting what is to be expected across each interface. For example, using the standard set (users, applications, devices, and networks), Figure 1.15 shows potential interfaces.

Click To expand
Figure 1.15: Generic system with interfaces added.

Although the description of the system given in Figure 1.15 is usually satisfactory for the start of most network architectures, there will be times when you will want to describe more components or have more defined interfaces. For example, the devicenetwork interface may be simple or complex, depending on what you are trying to accomplish. For a network that will be providing simple connectivity, the network-device interface may be a standard LAN interface (e.g., 100BaseT Ethernet) without any prioritization or virtual LAN (VLAN 802.1p/q) tagging. For a network that provides more than simple connectivity, such as quality of service, the device-network interface may be more closely coupled with the device or application. This may be accomplished by using drivers that bypass portions of the protocol stack and APIs that can interpret application performance requirements.

To illustrate, consider the difference in network-device interfaces between a network using ATM, a link-layer technology, in the backbone versus a network where devices directly connect to ATM, sometimes referred to as a native ATM network. Figure 1.16 shows a system description where ATM is used in the backbone and Ethernet is used to connect to the devices. In this description, ATM does not directly interface with the devices, applications, or users and is isolated from them by IP routers. This is one of the scenarios described in the classical model of IP over ATM, described in RFC 2225 (RFC is a request for comment, a standards document of the Internet Engineering Task Force [IETF]) and used in more detail in the design section of this book. In this system description, ATM is embedded within the network component of the set (users, applications, devices, and networks). Why is this important? By isolating ATM within the network component of the system, any capabilities specific to ATM that may be directly useful to devices, applications, or users of the system are lost.

Click To expand
Figure 1.16: Example of system with ATM in network.

Figure 1.17, on the other hand, shows a native ATM network in which ATM is integrated into devices and will interface directly with applications. In describing the system this way, we are explicitly including capabilities, such as quality of service, across the network-device interface. In this example the system may be better described as the set (users, applications, API, device driver, and network).

Click To expand
Figure 1.17: Example of system with native ATM.

You should consider more detailed system descriptions when there is a need to identify system components that are likely to affect the delivery of services to users. In Figure 1.17, the ATM-specific API translates application requirements to the ATM network. As part of the system description, this ATM-specific API is clearly recognized as being important to the delivery of services.

Although the system description is an attempt to identify components across the entire system, we need to recognize that most systems are not completely homogeneous and that components may change in various parts of the system. This usually occurs in parts of the system that perform specific functions, such as a device-specific network (e.g., a video distribution network) or a storage-area network (SAN). For example, although an SAN may be described as the set (users, applications, devices, and networks), users may be other devices in the system, and the only application may be for system storage and archival.


1.7 Service Description

The concept of network services in this book builds upon the services work from the IETF. This organization has been developing service descriptions for IP networks. In general, they see network services as sets of network capabilities that can be configured and managed within the network and between networks. We apply this concept to network analysis, architecture, and design, integrating services throughout the entire system. This will help you take advantage of the services concept by analyzing, architecting, and designing based on services, and it will also prepare you for the near future, when services will be configurable and manageable within the network.

Network services, or services, are defined here as levels of performance and function in the network. We can look at this from two perspectives: as services being offered by the network to the rest of the system (the devices, applications, and users) or as sets of requirements from the network that are expected by the users, applications, or devices. Levels of performance are described by the performance characteristics capacity, delay, and RMA (reliability, maintainability, and availability), whereas functions are described as security, accounting, billing, scheduling, and management (and others). This will be described in more detail in the next section.

It is important to note that the concept of services in this book is based on what networks can deliver to the system. Thus, it is not to be confused with services that other parts of the system (e.g., applications) can deliver to each other (e.g., graphics rendering services). When the term service is used in this book, it is in reference to network service.

Network services in most of today's networks are based on best-effort (unpredictable and unreliable) delivery. In addition to best-effort delivery, we will examine some new types of services, including high-performance, predictable (stochastic or probabilistic), and guaranteed services. These new services will require some different ways of looking at networks, and you will see how to incorporate such services into your architecture and design. We will also examine single-tier and multiple-tier performance in the network, how to distinguish between them, and how they relate to best-effort, predictable, and guaranteed services.

Network services are hierarchical, and individual service characteristics can be grouped together to form higher-level descriptions of a service, as shown in Figure 1.18.

Click To expand
Figure 1.18: Grouping characteristics into service levels and descriptions.


1.8 Service Characteristics

One of the goals of network analysis is to be able to characterize services so that they can be designed into the network and purchased from vendors and service providers (e.g., via requests for information [RFI], quote [RFQ], or proposal [RFP], documents used in the procurement process). In addition to today's best-effort delivery, we will also examine new types of services (predictable and guaranteed), as well as single/multipletier performance.

Service characteristics are individual network performance and functional parameters that are used to describe services. These services are offered by the network to the system (the service offering) or are requested from the network by users, applications, or devices (the service request). Characteristics of services that are requested from the network can also be considered requirements for that network.

Examples of service characteristics range from estimates of capacity requirements based on anecdotal or qualitative information about the network to elaborate listings of various capacity, delay, and RMA requirements, per user, application, and/or device, along with requirements for security, manageability, usability, flexibility, and others.

Example 1.3
Start example

Examples of service characteristics are:

  • Defining a security or privacy level for a group of users or an organization

  • Providing 1.5 Mb/s peak capacity to a remote user

  • Guaranteeing a maximum round-trip delay of 100 ms to servers in a server farm

End example

Such requirements are useful in determining the need of the system for services, in providing input to the network architecture and design, and in configuring services in network devices (e.g., routers, switches, device operating systems). Measurements of these characteristics in the network to monitor, verify, and manage services are called service metrics. In this book we focus on developing service requirements for the network and using those characteristics to configure, monitor, and verify services within the network.

For services to be useful and effective, they must be described and provisioned end-to-end at all network components between well-defined demarcation points. Note that this means that end-to-end is not necessarily from one user's device to another user's device. It may be defined between networks, from users to servers, or between specialized devices (Figure 1.19). When services are not provisioned end-to-end, some components may not be capable of supporting them, and thus the services will fail. The demarcation points determine where end-to-end is in the network. Determining these demarcation points is an important part of describing a service.

Click To expand
Figure 1.19: Various demarcation points for end-to-end in a network.

Services also need to be configurable, measurable, and verifiable within the system. This is necessary to ensure that end users, applications, and devices are getting the services they have requested (and possibly paying for), and this leads to accounting and billing for system, including network, resources. You will see how service metrics can be used to measure and verify services and their characteristics.

Services are also likely to be hierarchical within the system, with different service types and mechanisms applied at each layer in the hierarchy. For example, Figure 1.20 shows a service hierarchy that focuses on bulk traffic transport in the core of the network while placing specific services at the access network close to the end users, applications, and devices.

Click To expand
Figure 1.20: Example of service hierarchy within a network.

1.8.1 Service Levels

Service characteristics can be grouped together to form one or more service levels for the network. This is done to make service provisioning easier in that you can configure, manage, account, and bill for a group of service characteristics (service level) instead of a number of individual characteristics. For example, a service level (e.g., premium) may combine capacity (e.g., 1.5 Mb/s) and reliability (as 99.5% uptime). Service levels are also helpful in billing and accounting. This is a service-provider view of the network, where services are offered to customers (users) for a fee. This view of networking is becoming more popular in enterprise networks, displacing the view of networks as purely infrastructure of cost centers.

There are many ways to describe service levels, including frame relay committed information rates (CIRs), which are levels of capacity; ATM classes of service (CoSs), which combine delay and capacity characteristics; and IP types of service (ToSs) and qualities of service (QoSs), which prioritize traffic for traffic conditioning functions, which are described in the performance architecture (see Chapter 8). There can also be combinations of the aforementioned mechanisms, as well as custom service levels, based on groups of individual service characteristics. These combinations depend on which network technology, protocol, mechanism, or combination is providing the service.

In Figure 1.21 service offerings, requests, and metrics are shown applied to the system. In this example, demarcation of services is shown between the device and network components. Depending on the service requirement or characteristic, however, demarcation may also be between the device and application components (as in Figure 1.17).

Click To expand
Figure 1.21: Service requests, offerings, and metrics.
Example 1.4
Start example

A request from the customer was that each building should have Fast Ethernet (FE) capacity to the rest of the network. As part of the requirements analysis, this request became a requirement for 100 Mb/s peak capacity from the users in each building. This service request was then matched in the requirements and design processes by a technology choice that meets or exceeds the request; in this case, FE was chosen as the technology, and the service offering is 100 Mb/s to each building. Service metrics were then added, consisting of measuring the FE connections from the IP switch or router at each building to the backbone.

End example

Services and service levels can be distinguished by their degrees of predictability or determinism. In the next section we will discuss best-effort delivery, which is not predictable or deterministic, as well as predictable and guaranteed services.

Services and service levels are also distinguished by their degrees of performance. You will see how the service performance characteristics capacity, delay, and RMA are used to describe services and service levels.

1.8.2 System Components and Network Services

Network services are derived from requirements at each of the components in the system. They are end-to-end (between end points that you define) within the system, describing what is expected at each component. Service requirements for the network we are building are derived from each component: There can be user requirements, application requirements, device requirements, and (existing) network requirements. Since the network component is what we are building, any requirements from the network component come from existing networks that the new network will incorporate or connect to.

Component requirements add to each other, refining and expanding requirements as we move closer to the network. User requirements, which are the most subjective and general, are refined and expanded by requirements from the application component, which are then refined and expanded by the device and network components. Thus, requirements filter down from user to application to device to network, resulting in a set of specific requirements that can be configured and managed in the network devices themselves. This results in a service offering that is end-to-end, consisting of service characteristics that are configured in each network device in the path (e.g., routers, switches, hubs). As in Figure 1.22, service characteristics are configured and managed within each element and at interfaces between elements. These services are the most specific of all and have the smallest scope (typically a single network device).

Click To expand
Figure 1.22: Requirements flow down components to network.

Defining network services and service metrics helps keep the system functioning and can provide extra value or convenience to users and their applications. By defining service metrics, we are determining what we will be measuring in the network, which will help us in network monitoring and management.

Recall that network services are sets of performance and function, so requirements may also include functions of one of the components. Examples of functions include network monitoring and management, security, and accounting. Services such as these need to be considered an integral part of the network architecture and design. In this book, security (and privacy) and network management each have their own architectures. This may seem obvious, but traditionally, services such as security and network management have been afterthoughts in architecture and design, often completely forgotten in the architecture, until problems arise.

Example 1.5
Start example

The network path shown in Figure 1.23 was designed to optimize performance between users and their servers. The graph at the bottom of the figure is an estimate of the expected aggregate capacity at each segment of the path. In this network, a packet over SONET (POS) link at the OC-48 level (2.544 Gb/s) connects two routers, which then connect to Gigabit Ethernet (GigE) switches.

Click To expand
Figure 1.23: Capacity at each point in transmission path before security firewall.

After it was implemented, a security firewall was added at the users' LAN (with FE interfaces), without it being considered part of the original analysis, architecture, or design. The result was that the firewall changed the capacity characteristics across the path by reducing throughput between the user PCs and the GigE switch, as shown in Figure 1.24.

Click To expand
Figure 1.24: Capacity at each point in transmission path after security firewall.

End example

One of our architectural and design goals is to identify such performance bottlenecks before the network is implemented. By considering security, network management, services, and routing and addressing in the analysis process, we are much more likely to understand their behavior and effect on each other and the network. We will therefore be able to architect the network to accommodate their requirements and interoperability.

When service characteristics apply to individual network devices, such as routers, switches, data service units (DSUs), and so on, some of these characteristics may be vendor specific. In this book we will focus on those characteristics that are part of public standards and not vendor specific.

It is important to note that although standards-based characteristics are "standardized" on the basis of having their descriptions either publicly available (e.g., via an IETF RFC), sanctioned by an organization recognized by the networking community, or generally accepted and used as a de facto standard, the implementation of characteristics is open to interpretation and often varies across vendors and vendor platforms.

1.8.3 Service Requests and Requirements

Service requests and requirements are, in part, distinguished by the degree of predictability needed from the service by the user, application, or device making the request. Based on predictability, service requests are categorized as best effort, predictable, and guaranteed. Service requests and requirements can also be for single or multiple-tier performance for a network.

Best-effort service means that there is no control over how the network will satisfy the service request—that there are no guarantees associated with this service. Such requests indicate that the rest of the system (users, applications, and devices) will need to adapt to the state of the network at any given time. Thus, the expected service for such requests will be both unpredictable and unreliable, with variable performance across a range of values (from the network being unavailable to the lowest common denominator of performance across all of the technologies in the end-to-end path). Such service requests either have no specific performance requirements for the network or requirements that are based solely on estimates of capacity. When requirements are nonspecific, network performance cannot be tuned to satisfy any particular user, application, or device requirement.

Guaranteed service is the opposite of best-effort service. Where best-effort service is unpredictable and unreliable, guaranteed service must be predictable and reliable to such a degree that, when service is not available, the system is held accountable. A guaranteed service implies a contract between the user and provider. For periods when the contract is broken (e.g., when the service is not available), the provider must account for the loss of service and, possibly, appropriately compensate the user.

With best-effort and guaranteed services at opposite ends of the service spectrum, many services fall somewhere between. These are predictable services, which require some degree of predictability (more than best effort), yet do not require the accountability of a guaranteed service.

Predictable and guaranteed service requests are based on some a priori knowledge of and control over the state of the system. Such requests may require that the service operates either predictably or is bounded. Therefore, such services must have a clear set of requirements. For the network to provision resources to support a predictable or guaranteed service, the service requirements of that request must be configurable, measurable, and verifiable. This is where service requests, offerings, and metrics are applied.

Note that there are times when a service could be either best effort, predictable, or guaranteed, depending on how it is interpreted. Therefore, it is important to understand the need for a good set of requirements because these will help determine the types of services to plan for. Also, although the term predictable lies in a gray area between best effort and guaranteed, it is the type of service that is most likely to be served by most performance mechanisms, as we will see in Chapter 8.

For example, if a device requests capacity (bandwidth) of between 4 and 10 Mb/s, there needs to be a way to communicate this request across the network, a way to measure and/or derive the level of resources needed to support this request, a way to determine whether the required resources are available, and a method to control the information flow and network resources to keep this service between 4 and 10 Mb/s.

We can consider capacity to be a finite resource within a network. For example, the performance of a 100 Mb/s FE connection between two routers is bounded by that technology. If we were to look at the traffic flows across that 100 Mb/s connection, we would see that, for a common best-effort service, capacity would be distributed across all of the traffic flows. As more flows were added to that connection, the resources would be spread out until, at some point, congestion occurs. Congestion would disrupt the traffic flows across that connection, affecting the protocols and applications for each flow. What is key here is that, in terms of resource allocation, all traffic flows have some access to resources.

This is shown in Figure 1.25. In this figure, available capacity (dashed curve) decreases as the number of traffic flows increases. Correspondingly, the loading on the network (solid curve) from all of the traffic flows increases. However, at some point congestion affects that amount of user traffic that is being carried by the connection, and throughput of the connection (heavy curve) drops. As congestion interferes with the end-to-end transport of traffic, some protocols (e.g., TCP) will retransmit traffic. The difference between the loading and the throughput curves is due to retransmissions. This is undesirable, for while the connection is being loaded, only a percentage of that loading is successfully delivered to destinations. At some point, all of the traffic on that connection could be due to retransmissions and throughput approaches zero. This approach is used in best-effort networks.

Click To expand
Figure 1.25: Performance of Fast Ethernet connection under best-effort conditions.

In contrast, consider a telephony network. Calls are made on this network, and resources are allocated to each call. As more calls are added to the network, at the point where all of the resources have been allocated, additional calls are refused. The exiting calls on the network may suffer no performance degradation, but no new calls are allowed until resources are available. Call admission control (CAC) is a mechanism to limit the number of calls on a network, thereby controlling the allocation of resources.

This is shown in Figure 1.26. Individual calls are shown in this figure, and each call is 10 Mb/s for simplicity. As each call is accepted, resources are allocated to it, so the availability drops (dotted line) and loading increases (solid line) for each call. When the resources are exhausted, no further calls are permitted (dashed line). Congestion is not a problem for the existing calls, and throughput is maximized. This approach is similar to a guaranteed service.

Click To expand
Figure 1.26: Performance of Fast Ethernet connection under CAC.

There is a trade-off between these two approaches to resource allocation in a network. Although a best-effort network will allow access to as many traffic flows as possible, performance degradation across all of the traffic flows can occur. Admission control preserves resources for traffic flows that have already been allocated resources but will refuse additional traffic flows when resources are exhausted. In many networks, both approaches (or a hybrid between them) are desired. This will be discussed in detail in Chapter 8.

Service requests and requirements can also be low or high performance in terms of capacity, delay, and RMA. Low-and high-performance requirements depend on each particular network. A requirement is low or high performance relative to other requirements for that network. Low performance is an indicator that the service request or requirement's performance characteristics are less than a performance threshold determined for that network. Likewise, high performance is an indicator that the service request or requirement's performance characteristics are greater than a performance threshold determined for that network. Thus, in determining low and high performance for a network, we will develop one or more performance thresholds for that network. Multiple-tier performance indicates that there are multiple tiers of performance for that network. Single-tier performance requirements are roughly equivalent within a network.

Note that low and high performance are not described in terms of best-effort, predictable, or guaranteed service because they are independent of each other. Best-effort, predictable, and guaranteed service refer to the degree of predictability of a request or requirement, whereas low and high performance refer to a relative performance level for that request or requirement. For example, a network can be entirely best effort (most current networks are), yet we can often distinguish low-and high-performance requirements for such a network. And when a network has low-and high-performance regions for capacity, delay, and RMA, there may be predictable or guaranteed requirements in either region.

By their nature, each service has its associated set of requirements. These requirements are based on the levels of performance and function desired by the user, application, or device requesting service. Performance requirements are described in terms of capacity, delay, and RMA, whereas functional requirements describe specific functions needed in the service, such as multicast, security, management, or accounting. We will use requests for performance and function in developing the network architecture and design, for example, in describing the overall level of performance needed in the network.

As mentioned earlier, service performance requirements (capacity, delay, and RMA) can be grouped together, forming one or more service levels. For example, a service request may couple a specific capacity (e.g., 1.5 Mb/s) with a bound on end-to-end delay (e.g., 40 ms). At times, such service levels can be mapped to well-known service mechanisms such as ATM CoS, frame relay CIR, SMDS CoS, or IP ToS or QoS. Thus, service levels are a way to map performance and functional requirements to a well-known or standard network service offering. A properly specified service will provide insight into which performance characteristics should be measured in the network to verify service delivery.

1.8.4 Service Offerings

Service requests that are generated by users, applications, or devices are supported by services that are offered by the network. These service offerings (e.g., via ATM CoS, frame relay CIR, SMDS CoS, or IP ToS or QoS mentioned in the previous section) are the network counterparts to user, application, and device requests for service.

Service offerings map to service requests and thus can also be categorized as best effort, predictable, and guaranteed. Best-effort service offerings are not predictable— they are based on the state of the network at any given time. There is little or no prior knowledge about available performance, and there is no control over the network at any time. Most networks today operate in best-effort mode. A good example of a network that offers best-effort service is the current Internet.

Best-effort service offerings are compatible with best-effort service requests. Neither the service offering nor request assume any knowledge about the state of or control over the network. The network offers whatever service is available at that time (typically just available bandwidth), and the rest of the system adapts the flow of information to the available service (e.g., via TCP flow control).

Example 1.6
Start example

An example of a best-effort service request and offering is when a file transfer (e.g., using FTP) occurs over the Internet. FTP uses TCP as its transport protocol, which, via a sliding-window flow-control mechanism, adapts to approximate the current state of the network it is operating across. Thus, the service requirement from FTP over TCP is best effort, and the corresponding service offering from the Internet is best effort. The result is that, when the FTP session is active, the performance characteristics of the network (Internet) and flow control (TCP windows) are constantly interacting and adapting, as well as contending with other application sessions for network resources. In addition, as part of TCP's service to the applications it supports, it provides error-free, reliable data transmission.

End example

On the other hand, predictable and guaranteed service offerings have some degree of predictability or are bounded. To achieve this, there has to be some knowledge of the network along with control over the network in order to meet performance bounds or guarantees. Such services must be measurable and verifiable.

Just because a service is predictable or guaranteed does not necessarily imply that it is also high performance. For example, when using our definition of predictable service, the telephone network offers this type of service. Although at first look this may seem unlikely, consider the nature of telephone service. To support voice conversations, this network must be able to support fairly strict delay and delay variation tolerances, even though the capacity per user session (telephone call) is relatively small, or low performance. What is well known from a telephony perspective is somewhat new in the current world of data networking. Support for strict delay and delay variation is one of the more challenging aspects of data network architecture and design.

Predictable and guaranteed service offerings should be compatible with their corresponding service requests. In each case, service performance requirements (capacity, delay, and RMA) in a service request are translated into the corresponding performance characteristics in the service offering.

Example 1.7
Start example

An example of a predictable service request and offering can be seen in a network designed to support real-time streams of telemetry data. An architectural/design goal for a network supporting real-time telemetry is the ability to specify end-to-end delay and have the network satisfy this delay request. A real-time telemetry stream should have an end-to-end delay requirement, and this requirement would form the basis for the service request. For example, this service request may be for an end-to-end delay of 25 ms, with a delay variation of 400 s. This would form the request and the service level (i.e., a QoS level) that needs to be supported by the network. The network would then be architected and designed to support a QoS level of 25 ms end-to-end delay and delay variation of 400 s. Delay and delay variation would then be measured and verified with service metrics in the system, perhaps by using common utilities, such as ping (a common utility for measuring round-trip delay) or TCPdump (a utility for capturing TCP information), or by using a custom application.

End example

We will use various methods to describe service performance requirements and characteristics within a network, including thresholds, bounds, and guarantees. We will also learn how to distinguish between high and low performance for each network project.

This approach does not mean that best-effort service is inherently low performance or that predictable or guaranteed services are high performance. What this approach does is signify that predictability in services is also an important characteristic and is separate from performance. There are times when a network is best architected for best-effort service, and other times when best-effort, predictable, and guaranteed services are needed. We will see that when predictable or guaranteed services are required in the network, consideration for those requirements will tend to drive the architecture and design in one direction while consideration for best-effort service will drive the architecture and design in another direction. It will be the combination of all services that will help make the architecture and design complete.

1.8.5 Service Metrics

For service performance requirements and characteristics to be useful, they must be configurable, measurable, and verifiable within the system. Therefore, we will describe performance requirements and characteristics in terms of service metrics, which are intended to be configurable and measurable.

Since service metrics are meant to be measurable quantities, they can be used to measure thresholds and limits of service. Thresholds and limits are used to distinguish whether performance is in conformance (adheres to) or nonconformance (exceeds) with a service requirement. A threshold is a value for a performance characteristic that is a boundary between two regions of conformance and, when crossed in one or both directions, will generate an action. A limit is a boundary between conforming and nonconforming regions and is taken as an upper or lower limit for a performance characteristic. Crossing a limit is more serious than crossing a threshold, and the resulting action is usually more serious (e.g., dropping of packets to bring performance back to conformance).

For example, a threshold can be defined to distinguish between low and high performance for a particular service. Both low-and high-performance levels are conforming to the service, and the threshold is used to indicate when the boundary is crossed. This threshold can be measured and monitored in the network, triggering some action (e.g., a flashing red light on an administrator's console) when this threshold is crossed. An example of this might be in measuring the round-trip delay of a path. A threshold of N ms is applied to this measurement. If the round-trip times exceed N ms, an alert is generated at a network management station. We will discuss this in greater detail in the network management architecture.

In a similar fashion, limits can be created with service metrics to provide upper and lower boundaries on a measured quantity. When a limit is crossed, traffic is considered nonconforming (it exceeds the performance requirement) and action is taken to bring the traffic back into conformance (e.g., by delaying or dropping packets). Figure 1.27 shows how limits and thresholds may be applied in the system. In this figure, a threshold of 6 Mb/s is the boundary between low and high performance for a service requirement, and an upper limit of 8 Mb/s is the boundary between conformance and nonconformance for that service. When traffic crosses the 6 Mb/s threshold, a warning is sent to network management (with a color change from green to yellow). These notices can be used to do trend analysis on the network, for example, to determine when capacity needs to be upgraded. When traffic crosses the 8 Mb/s limit, the network takes action to reduce the capacity used by that traffic flow and an alert is sent to network management (with a color change from yellow to red) until the capacity level drops below 8 Mb/s and is again conforming.

Click To expand
Figure 1.27: Performance limits and thresholds.

Thresholds and limits are useful applications of service metrics to understand and control performance levels in the network, in support of services.


1.9 Performance Characteristics

Services may include one or more of the performance characteristics we have mentioned so far in this chapter: capacity, delay, and RMA. Each characteristic is actually a label for a class of characteristics of that type. For example, the term capacity is used as a label for the class of characteristics that involves moving information from place to place, including bandwidth, throughput, goodput, and so forth. Similarly, delay is a label for the class of characteristics that includes end-to-end delay, round-trip delay, and delay variation. RMA is a label for the class of characteristics that includes reliability, maintainability, and availability. Thus, when the terms capacity, delay, and RMA are used in this book, you can use other terms from each class, depending on your network.

There are times when it makes more sense to describe capacity in terms of throughput, for example, when developing requirements for applications. Round-trip delay is commonly used as a measure for delay, although at times delay requirements are expressed in terms of one-way delay.

1.9.1 Capacity

Capacity is a measure of the system's ability to transfer information (voice, data, video, or combinations of these). Several terms are associated with capacity, such as bandwidth, throughput, or goodput. Although we will use the generic term capacity throughout this book to reference this class of characteristics, you may choose to use another term in place of or along with capacity.

Bandwidth is the theoretical capacity of one or more network devices or communications links in the system. Theoretical, or raw, capacity does not take into account overhead from higher-layer protocols or the performance loss related to inefficiencies in the system (e.g., delays in the operating system or peripheral devices).

Throughput is the realizable capacity of the system or its network devices. Values for throughput vary, depending on system design, types and configurations of equipment, and where in the protocol stack the measurement for capacity is being taken.

Example 1.8
Start example

The bandwidth of a SONET OC-3c link is 155.52 Mb/s, which is three times the bandwidth of an OC-1 link (51.84 Mb/s). This bandwidth does not include data-link, network, or transport-layer protocol (e.g., ATM, IP, or transport control protocol/user datagram protocol [TCP/UDP]) overhead or, in the case of wide-area networks, the loss in performance due to the bandwidth delay product in the network. When a network or element is performing at its theoretical capacity, it is said to be performing at line rate. When an OC-3c circuit was tested, values of realizable capacity (throughput) ranged from approximately 80 to 128 Mb/s (measurements taken at the transport [TCP] layer of the National Research and Education Network [NREN] and Numerical Aerodynamic Simulation [NAS] networks, NASA Ames Research Center, March 1996).

A discussion on protocol overhead is presented in Chapter 11.

End example

Both bandwidth and throughput are important terms when describing system, network, application, and device capacities. Each gives a different and compatible view of capacity.

1.9.2 Delay

Delay is a measure of the time difference in the transmission of information across the system. In its most basic sense, delay is the time difference in transmitting a single unit of information (bit, byte, cell, frame, or packet) from source to destination. As with capacity, there are several ways to describe and measure delay. There are also various sources of delay, such as propagation, transmission, queuing, and processing. Delay may be measured in one direction (end-to-end) and both directions (round-trip). Both end-to-end and round-trip delay measurements are useful; however, only round-trip delays can be measured with the use of the practical and universally available utility ping.

Another measure of delay incorporates device and application processing, taking into account the time to complete a task. As the size of a task increases, the application processing times (and thus the response time of the system) also increase. This response time, termed here latency, may yield important information about the behavior of the application and the network. Latency can also be used to describe the response time of a network device, such as the latency through a switch or router. In this case the processing time is of that switch or router.

Delay variation, which is the change in delay over time, is an important characteristic for applications and traffic flows that require constant delay. For example, realtime and near-real-time applications often require strict delay variation. Delay variation is also known as jitter.

Together, delay (end-to-end and round-trip), latency, and delay variation help describe network behavior.

1.9.3 RMA

RMA refers to reliability, maintainability, and availability. Reliability is a statistical indicator of the frequency of failure of the network and its components and represents the unscheduled outages of service. It is important to keep in mind that only failures that prevent the system from performing its mission, or mission-critical failures (more on this in Chapter 2), are generally considered in this analysis. Failures of components that have no effect on the mission, at least when they fail, are not considered in these calculations. Failure of a standby component needs tending to but is not a mission-critical failure.

Reliability also requires some degree of predictable behavior. For a service to be considered reliable, the delivery of information must occur within well-known time boundaries. When delivery times vary greatly, users lose confidence in the timely delivery of information. In this sense the term reliability can be coupled with confidence in that it describes how users have confidence that the network and system will meet their requirements.

A parallel can be seen with the airline industry. Passengers (users) of the airline system expect accurate delivery of information (in this case the passengers themselves) to the destination. Losing or misplacing passengers is unacceptable. In addition, predictable delivery is also expected. Passengers expect flights to depart and arrive within reasonable time boundaries. When these boundaries are crossed, passengers are likely to use a different airline or not fly at all. Similarly, when an application is being used, the user expects a reasonable response time from the application, which is dependent on the timely delivery of information across the system.

Along with reliability is maintainability. Maintainability is a statistical measure of the time to restore the system to fully operational status after it has experienced a fault. This is generally expressed as a mean-time-to-repair (MTTR). Repairing a system failure consists of several stages: detection; isolation of the failure to a component that can be replaced; the time required to deliver the necessary parts to the location of the failed component (logistics time); and the time to actually replace the component, test it, and restore full service. MTTR usually assumes the logistics time is zero; this is an assumption, which is invalid if a component must be replaced to restore service but takes days to obtain.

To fully describe this performance class, we add availability to reliability and maintainability. Availability (also known as operational availability) is the relationship between the frequency of mission-critical failures and the time to restore service. This is defined as the mean time between mission-critical failures (or mean time between failures) divided by the sum of mean time to repair and mean time between missioncritical failures or mean time between failures. These relationships are shown in the following equation, where A is availability.

A = (MTBCF)/(MTBCF + MTTR) or A = (MTBF)/(MTBF + MTTR)

Capacity, delay, and RMA are dependent on each other. For example, the emphasis of a network design may be to bound delay: A system supporting point-of-sale transactions may need to guarantee delivery of customer information and completion of the transaction within 15 seconds (where the network delay is on the order of 100s of ms); a Web application can have similar requirements. However, in a computeintensive application we may be able to optimize the system by buffering data during periods of computing. In this case, delay may not be as important as a guarantee of eventual delivery. On the other hand, a system supporting visualization of real-time banking transactions may require a round-trip delay of less than 40 ms, with a delay variation of less than 500 s. If these delay boundaries are exceeded, the visualization task fails for that application, forcing the system to use other techniques.

1.9.4 Performance Envelopes

Performance requirements can be combined to describe a performance range for the system. A performance envelope is a combination of two or more performance requirements, with thresholds and upper and/or lower limits for each. Within this envelope, levels of application, device, and/or network performance requirements are plotted. Figures 1.28 and 1.29 show two such envelopes. The performance envelope in Figure 1.28 consists of capacity, in terms of data sizes transferred across the network, and end-to-end delay. In this figure, delay is shown as 1/delay for consistency.

Click To expand
Figure 1.28: Example of a 2D performance envelope.
Click To expand
Figure 1.29: Example of a 3D performance envelope.

Figure 1.29 is a 3D performance envelope, showing capacity, delay, and RMA. This envelope also describes two regions of performance, low and high performance, which are functions of the limits and thresholds for capacity, delay, and RMA.

Performance envelopes such as these are useful for visualizing the regions of delay, capacity, and RMA in which the network will be expected to operate based on requirements developed for that network. In Chapter 2 we will discuss how requirements are developed for a network.


1.10 Network Supportability

The ability of the customer to sustain the required level of performance (that architected and designed into the network) over the entire life cycle of the network is an area of networking that is often neglected. It is a mistake to assume that a successful network architecture and design meets the requirements only on the day that it is delivered to the customer and that future requirements are the responsibility of the customer.

Experience indicates that 80% of the life cycle costs of a system are the operations and support costs, and only 20% is the cost incurred to develop, acquire, and install it. Good network architects/designers will take into account the major factors that affect operability and supportability as they make their decisions. Knowledgeable customers will insist that they understand the operations and support implications of a network architecture and design. At times, such issues may be of more concern than the feasibility of a new technology.

The postimplementation phases of a network's life cycle can be broken into three elements: operations, maintenance, and human knowledge. The operations element focuses on ensuring that the network and system are properly operated and managed and that any required maintenance actions are identified. The maintenance element focuses on preventive and corrective maintenance and the parts, tools, plans, and procedures for accomplishing these functions. The human knowledge element is the set of documentation, training, and skilled personnel required to operate and maintain the network and system. Design decisions affect each of these factors and have a direct impact on the ability of the customer to sustain the high level of service originally realized upon implementation of the network.

Failure to consider supportability in the analysis, architecture, and design processes has a number of serious consequences. First, a smart customer, when faced with a network architecture/design that obviously cannot be operated or maintained by his or her organization, will reject the network project or refuse to pay for it. Second, a customer who accepts the architecture/design and subsequent implementation will have inadequate resources to respond to network and system outages, experience unacceptable performance after a period of time, and may suffer adverse effects in his or her operation or business (e.g., a loss of their customers or revenue). Other customers will be highly dissatisfied with their networks and either require the architect/designer to return and repair it by providing adequate materials to sustain its required performance level or will prematurely replace it. None of these cases reflects positively on the network architect/designer or implementation team and often lead to finger pointing that can be more painful than any acceptance test.

Key characteristics of a network architecture and design that affect the postimplementation costs include:

  • Network and system reliability

  • Network and system maintainability

  • Training of the operators to stay within operational constraints

  • Quality of the staff required to perform maintenance actions

Some examples of key network architecture/design decisions that affect these characteristics include:

  • Degree of redundancy of critical-path components in network architecture/design

  • Quality of network components selected for installation

  • Location and accessibility of components requiring frequent maintenance

  • Implementation of built-in test equipment and monitoring techniques

Supportability must be considered throughout the life cycle of the network. An accurate assessment of the requirements for continuous service at full performance level must be included in the requirements analysis process, along with a statement of specific, measurable requirements. During the architecture and design processes, trade-offs must take into account the impact of supportability and the concept of operations must be formulated. Last, during implementation, two major tasks must be accomplished to ensure supportability:

  1. Conformance to the network architecture and design must be validated and nonconformance corrected or (at least) documented to ensure that performance is adequate and that maintenance can be performed.

  2. Operations and maintenance personnel must understand and be trained in the technologies that are being deployed, including how to operate the network and system properly, when to perform maintenance, and how to most quickly restore service in the event of a fault.

A detailed discussion of how supportability fits into the overall architecture and design processes is provided in Chapter 2.


1.11 Conclusion

In this chapter you learned definitions of network analysis, architecture, and design; the importance of network analysis in understanding the system and providing a defensible architecture and design; and the model for the network analysis, architecture, and design processes.

You have also learned that networks are not independent entities but rather a part of the system and that the delivery of network services is a goal of the system. Network services consist of performance and function and are offered to users, applications, and devices so that they can accomplish their work on the system. In order to architect and design a network to support services, you need to know what they are, how they work together, and how to characterize them. Once you do this, you will have a broad view of what the network will need to support, which you can take to the next levels of detail as you proceed with the network analysis.

By describing the system as a set of components (e.g., user, application, device, network), you can apply interfaces between these components to help understand the relationships, inputs, and outputs between each of the components.

You have also learned about different types of services, from best-effort, unpredictable, and unreliable service to predictable, bounded, and somewhat predictable service, to guaranteed services with accountability.

To go to a level deeper in the discussion about services, we considered the service performance characteristics capacity, delay, and RMA (reliability, maintainability, and availability). These characteristics will be useful only if we can measure and verify their values in the system. We discussed these values, as well as service metrics, thresholds, and boundaries. We learned that performance characteristics could be combined into a performance envelope.

Having thought about systems, services, and their characteristics, we are now ready to quantify what we want from our networks. To do this, we first need to gather, analyze, and understand the requirements from the system. This is requirements analysis, the next step in the network analysis process.


1.12 Exercises

  1. In Example 1.1, an analogy was drawn between a network's architecture and design and a home's architecture and design. Provide a similar analogy, using a computer's architecture and design.

  2. Hierarchy and interconnectivity are a fundamental trade-off in networks. Given the network hierarchy shown in Figure 1.30, with costs assigned to each link, show how interconnectivity would improve the performance of traffic flowing between Joe's computer and Sandy's computer. Costs are shown as numbers but could represent the capacity of each link or the costs incurred by using each link. What is the total cost of traveling the hierarchy between Joe's computer and Sandy's? In this figure, where would you add a link of cost 15 so that the total cost between Joe's computer and Sandy's is less than it is when you travel the entire hierarchy?

    Click To expand
    Figure 1.30: Network hierarchy for Exercise 2.

  3. In Figure 1.9, connections are added between networks in the Internet to provide a better performing path for select traffic flows. An example of this is a content delivery network (CDN). What is a CDN? Show how a CDN uses interconnectivity to provide better performance characteristics to its users.

  4. In defining where services can be applied in a network, end-to-end is determined by where you want a service to start and stop. For example, if your WAN is supplied by a service provider (e.g., an ATM or frame relay service), you may want to define the end points and characteristics of that service. If you use IP routers at each LAN-WAN interface to that service, describe the following: (1) at which network devices would you define the end points of the service, and (2) what characteristics (service metrics) would you use to measure the service?

  5. Service requirements flow from user to application to device to network, becoming more specific along the way. If you were given an application requirement for end-to-end delay (e.g., 100 ms) between an application server on one network and users on another network, for example, how might that translate into delay in the network and devices? What types of service metrics could you use to measure it?

  6. For Example 1.5, the delay characteristics for the segments (including the processing at the switches) are as follows: for each GigE segment, 100 s; for the PoS OC-48 segment between routers, 1 ms; for each FE segment, 200 s; and for the security firewall, 5 ms. Draw graphs showing the end-to-end delay performance (in the direction from user PC to server) before and after the security firewall is added.

  7. Which of the following applications require best-effort (unpredictable and unreliable), guaranteed (predictable and reliable, with accountability), or predictable service. Give reasons for your choices.

    • High-quality (phone company-grade) voice calls

    • Voice over IP (VoIP) calls

    • File transfers via FTP

    • Audio file downloads

    • A commercial video-on-demand service

    • User access to servers in a corporation

  8. Show how performance boundaries and thresholds could be used in the following scenarios.

    • An application has a service requirement for round-trip delay to be less than 100 ms. If delay is greater than 100 ms, notify the network administrator.

    • A user requires capacity of up to 512 Kb/s but may not exceed 1.5 Mb/s. You want to keep track of how much time the user's capacity is between 512 Kb/s and 1.5 Mb/s.


Chapter 2: Requirements Analysis: Concepts

In this chapter you will learn to develop service descriptions for networks and how to identify and/or derive network requirements from the system. You will learn that network requirements are coupled to services, and you will develop a requirements specification to map out requirements and help determine their dependencies. You will learn how to apply the concepts discussed in the last chapter to a variety of user, application, and device requirements, you will also learn to develop both a requirements specification and applications map.

2.1 Objectives

In this chapter we will expand the concept of requirements for a network. We will tune the general systems engineering process, introduced in the previous chapter, to the problem of networking. You will learn about different types of requirements from the user, application, device, and network components. You will learn about grouping requirements together and mapping the locations of applications and devices. The combination of all the requirements and locations will be expressed in two documents: a requirements specification and requirements map.


2.2 Preparation

There is little information on the requirements analysis process as it applies to networking. However, there are some excellent preparatory materials that are of a more general systems engineering nature that will provide an overview of the requirements analysis process. The following books are recommended:

  • The Art of Systems Architecting, 2nd edition, by Mark W. Maier and Eberhardt Rechtin, CRC Press, June 2000

  • Requirements Engineering: A Good Practice Guide, by Ian Sommerville and Pete Sawyer, John Wiley & Sons, April 1997

  • Enterprise System Architectures: Building Client Server and Web Based Systems, by Mark Goodyear, CRC Press, September 1999

  • Systems Engineering: Coping with Complexity, by Stuart Arnold, Peter Brook, Ken Jackson, and Richard Stevens, Prentice Hall, June 1998


2.3 Background

As you may already have noticed, the network analysis part of this book, consisting of requirements, flow, and risk analyses, introduces many new concepts and guidelines and expands upon several existing concepts. Therefore, requirements analysis and flow analysis are separated into three chapters, covering concepts and procedures, respectively, in order to make this material more readable and useful. The chapters on concepts provide background material for each topic, explaining and defining pertinent concepts. The chapters on procedures expand on these concepts to build a process for you to apply to your architectures and designs.

We begin the network analysis process with requirements analysis, which is gathering and deriving requirements in order to understand system and network behaviors. This consists of identifying, gathering, deriving, and understanding system requirements and their characteristics; developing thresholds and limits for performance to distinguish between low- and high-performance services; and determining where best-effort, predictable, and guaranteed services may apply in the network.

2.3.1 Requirements and Features

Requirements are descriptions of network functions and performance that are needed for the network to successfully support its users, applications, and devices. Using this definition, every requirement for the network must be met for it to be successful. Yet, as we will see, there can be many requirements, from a variety of sources, with varying degrees of achievability. If we consider all requirements from all sources as being necessary to the success of the network, we are likely setting expectations that cannot be met. Thus, as part of the requirements analysis process, we will prioritize requirements, determining which are truly requirements for the network and which may be desirable but are not truly requirements.

Network functions and performance that are desired but not necessary for the network to successfully support its users, applications, and devices are called features. There will be requirements that, as part of the analysis process, are determined to be features for the network. In addition, there will be requirements that may be considered in a later version of the network, those that will be rejected during the analysis process, and those that are more informational than required.

As shown in Figure 2.1, requirements are separated into core or fundamental requirements (those deemed necessary for that network), features that are desirable for that network, those that may be considered in a later version or upgrade of the network, and requirements that have been rejected (e.g., not really necessary or desirable, not realistic, not implementable). Each network should have, as a minimum, a set of core requirements; in addition, each will probably have a set of informational requirements and may have sets of features, future requirements, and rejected requirements.

Click To expand
Figure 2.1: Requirements are separated into core/fundamental requirements, features, future requirements, and rejected and informational requirements.

Requirements are categorized during the requirements analysis process, through discussions with users, management, and staff, and are approved (signed off on) by management. In practice, a first attempt at categorization, done by the analysis group, is presented to management to determine whether this categorization is on the right track. If so, it is further developed with input from users, management, and staff.

One method to categorize requirements is based on current practice of the Internet Engineering Task Force (IETF). RFC 2119 identifies key words and phrases that can be used to describe the relative importance of a requirement. These key words and phrases are must/shall/required, must not/shall not, should/recommended, should not/not recommended, and may/optional. Each of these terms is defined here.

  • Must/Shall/Required. These key words indicate an absolute requirement and would be included as core or fundamental requirements for the network.

  • Must Not/Shall Not. These are also absolute requirements indicating a restriction or prohibition of a function or task. These would also be included as core or fundamental requirements for the network.

  • Should/Recommended. These key words indicate that a requirement may be valid but that its implementation is not absolutely necessary for the success of the network. Such requirements would be categorized as features or future requirements for the network.

  • Should Not/Not Recommended. As with should/recommended, these phrases indicate that a requirement may be valid (in this case to prohibit a function or task) but that its implementation is not absolutely necessary for the success of the network. Such requirements would also be categorized as features or future requirements for the network

  • May/Optional. When a requirement is truly optional, it may be categorized as a feature or future requirement, or it may be rejected.

By using these terms, you help ensure that there is no confusion regarding requirements and features. We will discuss the categorization of requirements in greater detail at the end of this chapter, when we develop the requirements specification.

2.3.2 The Need for Requirements Analysis

Why do requirements analysis? Although requirements analysis is fundamental to the network architecture and design, it is often overlooked or ignored. Why is this the case? A major reason that requirements analysis is not given proper consideration is the degree of difficulty involved. Gathering requirements means talking to users, network personnel, and management and interpreting the results. Talking to N users may result in N + 1 different sets of user requirements. Network personnel and management are often distanced from the users and do not have a clear idea of what users want or need. In addition, requirements analysis may appear to offer no immediate payoff. Finally, requirements analysis means putting thought and time into preparing for the architecture and design.

A result of not doing proper requirements analysis is that the network architecture and design end up being based on factors other than what the users, applications, or devices need. For example, the network may be based on a particular technology, typically one that the designer feels most comfortable with. Another example is a network based on a particular vendor's equipment, again often one that the designer feels comfortable with. An obvious example is having a budget constraint or deadline that forces the designer to make do and use familiar, easy-to-apply technologies. Problems with these choices are that they are not objective and that familiar technologies or vendors may not be the right choices for that particular network.

Requirements analysis helps the designer better understand the probable behavior of the network being built. This results in several payoffs:

  • More objective, informed choices of network technologies and services

  • The ability to match interconnection strategies to networks

  • Networks and elements properly sized to users and applications

  • A better understanding of where and how to apply services in the network

In addition, trade-offs in the architecture and design need to be performed with the total picture in mind. Sometimes this does not become clear until all users, management, and staff have been consulted and all requirements identified. Many re-design efforts result from an initially incomplete set of requirements.

As you proceed through the rest of this book, you will see that the requirements analysis process forms the foundation upon which the network architecture and design processes are built.

In the requirements analysis process, we will use requirements to distinguish between low- and high-performance applications for our networks; identify specific services; gather performance requirements for use in flow analysis; and gather other requirements to be used throughout the analysis, architecture, and design processes. We will see that low and high performance are relative to the network we are working on, and we will develop and apply performance thresholds and limits to help us distinguish between them.

As you will see, the results of requirements analysis are the requirements specification and requirements map. A requirements specification is a document that lists and prioritizes the requirements gathered for your architecture and design. The requirements map shows the location dependencies between applications and devices, which will be used for flow analysis.

Throughout this section (and the others in this book), guidelines will be presented regarding how each process may be implemented. These guidelines are from practical experience and should be used as a starting point for you to develop your own set of guidelines. As we proceed, you are encouraged to think about how each guideline could be implemented and how you would add to or modify it.


2.4 User Requirements

From the model of system components in our generic system, the user component is at the highest layer. The term user represents primarily the end users of the system, but it can be expanded to include everyone involved in the system, such as network and system administrators and management. User requirements is the set of requirements gathered or derived from user input and is what is needed by users to successfully accomplish their tasks on the system. Typically, when gathering requirements, everyone involved with that network is considered a potential user. Figure 2.2 shows some example user requirements.

Click To expand
Figure 2.2: Types of user requirements.

We begin describing requirements at this layer, which will lead to the development of more specific requirements as we work through each of the components.

From the user perspective, we can ask, "What does it take to get the job done?" This will usually result in a set of qualitative, not quantitative, requirements. Part of our job in gathering and deriving user requirements is to make them quantitative whenever possible.

In general, the system should adapt to users and their environments, provide quick and reliable information access and transfer, and offer quality service to the user. This indicates the following general requirements:

  • Timeliness

  • Interactivity

  • Reliability

  • Presentation quality

  • Adaptability

  • Security

  • Affordability

  • Functionality

  • Supportability

  • Future growth

User requirements are the least technical and are also the most subjective. As shown in Figure 2.3, requirements become more technical as they move from users to the network. All of these requirements will be developed in more detail as we proceed through the application, device, and network components.

Click To expand
Figure 2.3: Requirements become more technical as we move closer to network devices.

The intent is to use them as a start toward developing more objective and technical requirements in the other components. These example requirements are presented as a guide for you to use in developing requirements for your network, and they may change depending on the user's environment.

Timeliness is a requirement that the user is able to access, transfer, or modify information within a tolerable time frame. What a "tolerable" time frame is, of course, depends on the user's perception of delay in the system. It is this perception that we want to quantify. For example, a user may want to download files from a server and complete each transfer within 10 minutes. Or the user may need to receive video frames every 30 ms. Each one of these times indicates a delay that the network will need to provide. For timeliness, end-to-end or round-trip delay can be a useful measurement.

Interactivity is similar to timeliness but focuses on a response time from the system (as well as the network) that is on the order of the response times of users. In the preceding example, we could consider the 10 minutes needed to download a file as the response time for the system. We further say that the file transfer is interacting with the user (which it is), but the degree of interactivity in this example is very low and not of much interest from an architectural or design perspective. What is interesting is when the system and network response times are close to the response times of users, for then changes that are made in the network architecture and design to optimize response times can have a direct impact on users' perception of interactivity. Therefore, interactivity is a measure of the response times of the system and network when they are required to actively interact with users. Delay, here the round-trip delay, is a measure of interactivity. Using these descriptions of timeliness and interactivity, timeliness is more likely to be associated with bulk file or image transfer, whereas interactivity is likely to be associated with remote device access (e.g., telnet), Web use, or visualization.

Reliability, that is, availability from the user's perspective, is a requirement for consistently available service. Not only must the user be able to have access to system resources a very high percentage of the time, but the level of service to the user (in terms of application usage or information delivery) must be consistent. Thus, reliability is closely related to the performance characteristic reliability (discussed in Chapter 1 as part of RMA), but delay and capacity are also important. It is likely that a combination of all performance characteristics would be used to describe reliability.

Presentation quality refers to the quality of the presentation to the user. This may be the user's perception of audio, video, and/or data displays. As examples, consider the current Internet capabilities of video conferencing, video feeds (live or delayed), and telephony. Although it is possible to do all of these on the Internet, there are other mechanisms that currently provide much better presentation quality. It is often not sufficient to provide a capability over a network—that capability must be as good or better than other mechanisms, or the user will be disappointed. Network architects and designers often miss this concept. Measures of quality include all of the performance characteristics.

Adaptability is the ability of the system to adapt to users' changing needs. Some examples of this are in distance-independence and mobility. As users rely more and more on the network, they are becoming coupled to logical services and decoupled from physical servers. This decoupling means that users do not have to care where servers are located, as long as they can get the services they need. A result of this is distance-independent computing, where the user loses all knowledge of where jobs are being executed, or where data are sourced, stored, or migrated through the network. Mobility refers to mobile or nomadic computing, where the user can access services and resources from any location, using portable devices and wireless access to the network. Adaptability to such user needs forces requirements on the system architecture and design.

Security from the user perspective is a requirement to guarantee the confidentiality, integrity, and authenticity of a user's information and physical resources, as well as access to user and system resources. Security is probably closest to the performance characteristic reliability, but it will affect capacity and delay as well.

Affordability is the requirement that purchases fit within a budget. Although this requirement is not technical, it will affect the architecture and design. Our goal in this requirement is to determine what users or management can afford to purchase for the network so that our architecture and design do not cost too much to implement. As a user requirement, we are looking for how costs and funding are tied to users, groups of users, and management. We will also discuss funding as a system-wide requirement, from an overall budget perspective.

Functionality encompasses any functional requirement that the user will have for the system. Functions that the system will perform are often tied to applications that are used on the system. Understanding functionality is important in that it will lead into application requirements (covered in the next section). Part of understanding functionality is determining which applications users actually want or apply in their daily work. We do not want to analyze applications that no one is planning to use.

Supportability is a set of characteristics that describe how well the customer can keep the network operating at designed performance through the full range of mission scenarios described by the customer during the requirements analysis process. This includes how users want or need to be supported by their network operations staff and any interfaces they will have with a network operations center (NOC). For example, will the network need to be reconfigured to meet different or changing user needs? What applications will the network operations staff and/or NOC need to provide support to users and to identify and troubleshoot problems on the network? Information such as this will be used later as input to the network management architecture.

Future growth is determining if/when users are planning to deploy and use new applications and devices on the network.

In addition to these requirements, we will want to know how many users will be expected on the network and their locations. If possible, estimate what the growth in users will be over the first 1 to 3 years after the network is planned to be operational, or for what you expect the life cycle of the network to be.


2.5 Application Requirements

The application component interfaces with the user and device components and is a key part of the requirements analysis. Application requirements are requirements that are determined from application information, experience, or testing; applications need these to successfully operate on the system.

Figure 2.4 shows example application requirements. Application requirements are more technical than user requirements but may still be subjective.

Click To expand
Figure 2.4: Types of application requirements.

2.5.1 Application Types

In the system description (user, application, device, and network), the application component is pivotal. This component is often where many requirements for the network are determined, as applications couple users and devices to the network. Applications are often end-to-end, between multiple devices; thus their requirements span the underlying network.

In the early days of networking, applications required basic connectivity and data transfer across the network. Although applications still have these requirements, they are often also required to be high performance or to have predictable or guaranteed behavior to support user requirements for timeliness, interactivity, reliability, quality, adaptability, and security. Thus, user requirements have an impact on application requirements. We can use these service and performance requirements to distinguish between applications that need predictable or guaranteed service and those that can use best-effort service.

Based on service and performance requirements, we will type applications as mission-critical, rate-critical, and real-time/interactive, where:

  • Mission-critical applications have predictable, guaranteed, and/or high-performance RMA requirements.

  • Rate-critical applications have predictable, guaranteed, and/or high-performance capacity requirements.

  • Real-time and interactive applications have predictable, guaranteed, and/or high-performance delay requirements.

These application types will be described by their requirements and service metrics.

RMA

Let's first look at RMA, consisting of reliability, maintainability, and availability. Reliability is a statistical measure of the frequency of failure of the network and its components; it represents the unscheduled outages of service. Maintainability is statistical measure of the time to restore the system to fully operational status after it has experienced a fault. Availability is a measure of the relationship between the frequency of mission-critical failures and the time to restore service. How do these measures relate to the applications that will use the network?

RMA requirements can be subjective. Many users argue that their applications require a high degree of reliability, maintainability, and/or availability from the network, but there are some applications that must maintain high degrees of RMA in order to function. A loss of any part of RMA in such applications may be serious or disastrous, such as:

  • Loss of revenue or customers. An application that handles a lot of transactions and money, such as investment banking, airline reservation, or credit card processing applications, is an example.

  • Unrecoverable information or situation. Telemetry processing and teleconferencing applications are good examples of this type of reliability.

  • Loss of sensitive data. Examples include customer ID/billing and intelligence-gathering applications.

  • Loss of life. Examples include transportation or health care monitoring applications.

In these situations, either the system is not available to process user/application requests or the system is not available to complete the transactions that are in progress. For applications such as these, a network that offers only best-effort service is not likely to be sufficient due to its unpredictable and unreliable behavior. These applications require predictable or guaranteed reliability, maintainability, and availability, which may take the form of a predictable or bounded RMA, or a high degree of RMA, or both. Applications that require predictable or high RMA are termed here mission-critical applications.

Capacity

In terms of capacity, some applications require a predictable, bounded, or high degree of capacity. Such applications, termed here rate-critical applications, include voice, non-buffered video, and some tele*service applications (applications that provide a subset of voice, video, and data together to be delivered concurrently to groups of people at various locations, e.g., teleconferencing, telemedicine, teleseminars [thus the tele*]). Rate-critical applications may require thresholds; limits; or guarantees on minimum, peak, and/or sustained capacities.

Note the difference between rate-critical applications and best-effort applications such as traditional file transfer (where the file transfer application is not written to operate only when a predictable or guaranteed service is available). In file transfer (such as in FTP running over TCP, described earlier), the application receives whatever capacity is available from the network based on the state of the network at that time and the interactions between TCP and the lower layers. Although at times this may be a high degree of capacity, it is inconsistent and there is no control over the resources in the network to predict or guarantee a specific (usually minimum) capacity to function properly. This can often also be tied to the end-to-end delay of the network, for capacity will affect delay.

Delay

Increasing interactivity is arguably the driving force behind the evolution of many applications. Consider the evolutionary path of information access, from telnet and FTP to Gopher and Archie (Gopher is a menu system that simplifies locating resources on the Internet, and Archie is a database that consists of hundreds of file directories) to Mosaic (the precursor to Netscape) and Netscape, made even more interactive with the use of JAVA and virtual reality markup language (VRML). As we saw in the previous section, interactivity relies predominantly on the performance characteristic delay.

Delay is a measure of the time differences in the transfer and processing of information. There are many sources of delay, including propagation, transmission, queuing, processing, and routing. This section focuses on end-to-end and round-trip delays, which encompass all of the delay types mentioned earlier. From an application service perspective, optimizing the total, end-to-end or round-trip delay is usually more important than focusing on individual sources of delay. Individual sources of delay become more important as we get into the lower-layer components, as well as in architecture and design optimizations.

Historically, applications used on the Internet did not have strict delay requirements. They relied on best-effort service from the Internet and did not request or expect any service guarantees. Other applications, found primarily on private networks (with proprietary network technologies and protocols), have had more strict delay requirements (as well as capacity and RMA requirements). Some private networks have been effective in providing predictable or guaranteed delay, either through overengineering of the network with substantial spare capacity or at the trade-off of interoperability with other networks. But we now find that applications with delay requirements are migrating to the Internet, often using VPNs, and applications previously dedicated to a single user or device are now being used across the Internet, forcing a reevaluation of offering services other than best effort on the Internet. This is also forcing a reevaluation of traffic engineering techniques by service providers.

The term real-time has been interpreted to mean many different things. Often, real-time means "as fast as possible" by those who do not know, understand, or care about the actual delay relationships between traffic sources and destinations within their network. It is quite difficult to quantify real-time when it is used this way. There are more meaningful ways to describe real-time, as well as non-real-time, interactive, asynchronous, burst, and bulk. These are all described in the following sections.

Real-time applications are those that have a strict timing relationship between source and destination, with one or more timers set for the receipt of information at the destination. Information received after the timers expire at the destination is considered worthless and is dropped. Thus, this definition of real-time does not mean that information has to be transferred within a universally known time boundary but rather that the delay boundary is understood by source and destination and that the destination does not wait beyond this boundary. Real-time could mean end-to-end delays of 30 ms for some applications and 30 seconds for others. An example of this is nonbuffered video playback. If the video stream is delayed beyond the playback timer, the destination will show one or more blank portions of frames (appearing as blips on the screen) and drop the late video. This is done to preserve the time continuity of the video being shown at the playback device. This is what having a strict timing relationship between source and destination means—that the information flow is subject to maintaining time continuity.

Real-time is the first of several terms we need to clarify. These terms are often used carelessly, although, as the network architect/designer, we have to take them seriously. Therefore, it is up to us to make sure that ambiguous terms, as well as requirements based on such terms, are clarified. This book tries, whenever possible, to provide strict interpretations of such terms to help make them clear.

Given this strict interpretation of real-time, there obviously are not that many real-time applications. But there are some (and their numbers are growing), and it is important to be able to identify them and recognize their strict delay requirements, for they can have a strong impact on the network architecture and design.

Currently, most applications are considered non-real-time. Non-real-time applications have various end-to-end delay requirements, at times more stringent (in terms of the amount of delay) than real-time applications, but the important factor here is that the destination will wait (within reason) until the information is received. How long the destination will wait is a function of the timers set in the applications, at the devices, and by the protocols used. Non-real-time applications include interactive and asynchronous, which account for the vast majority of applications.

With real-time applications at one extreme of performance, asynchronous applications are at the other extreme. Asynchronous applications are relatively insensitive to time, either assuming no timing relationship between source and destination or that the timing relationship is outside the bounds of the applications session. A good example of an asynchronous application is email. When email is sent to a recipient, all knowledge of timing (i.e., the time when the email is received at any intermediate stop or at the final destination) is lost to the sender. Only if there is an error in the system or recipient information, or if it is requested, is the sender notified. Facsimile is another asynchronous application. When a fax is sent (when it is buffered in the sending device), the sender loses any knowledge of when the fax arrives at its destination.

Just as it is important to identify real-time applications, because of their strict timing requirements, it is also important to identify asynchronous applications, because of their lack of timing requirements. Asynchronous applications have little or no effect on the network architecture and design and can usually be ignored.

Just as there are not many real-time applications, there are also not many asynchronous applications. Thus, most applications fall in the non-real-time realm, between real-time at one extreme and asynchronous at the other extreme. These applications are called interactive. Interactive applications assume some timing relationship between source and destination while the application session is active; however, the timing relationship is not as strict as in real-time. Interactive applications are what many people would normally consider real-time, under the connotation of real-time as "as fast as possible." Common interactive applications, such as telnet, FTP, and Web applications, all fall under this classification.

Finally, interactive applications may be further subdivided into burst and bulk interactive types. The difference between these types is subtler than with real-time or asynchronous applications. To distinguish between interactive bulk and burst applications, we need to first understand when the processing times of the system components, particularly the application component, overwhelm the end-to-end or round-trip delay of the network. In other words, we want to distinguish between when an application will frequently and quickly interact with a user and when a user will have to wait substantial periods of time while the application is processing information. These delay types are summarized in Figure 2.5.

Click To expand
Figure 2.5: Delay types.

Based on this, interactive burst applications are those in which the end-to-end or round-trip network delay is the predominant delay for that application. This type of application is important to identify, for it is sensitive to network delay. Thus, the network architecture and design will need to accommodate the delay requirements from these applications. An example of an interactive burst application is telnet. During a telnet session, the predominant delay experienced by the user is from the network, not from any processing at the local or remote devices. There are many applications of this type, where users interact with applications and devices across the network and expect responses "as fast as possible."

Interactive bulk applications are those in which the end-to-end or round-trip network delay is not the predominant delay for that application; rather processing at the device or application component is the predominant delay. Thus, processing information at either or both end points overwhelms the end-to-end or round-trip times in the network. This is important to recognize—the network delay requirement by that application becomes less significant because it is already eclipsed by application and/or device delays. For example, when an application has high processing delays, say on the order of 100s of milliseconds or seconds then we have more flexibility in supporting delay in the network than if the processing delay was on the order of microseconds. An example of interactive bulk applications is large file transfer (e.g., FTP). Although FTP has an degree of interaction with the user, there can be times (especially when the file size is large) when the processing of information at the receiving end, as well as the overall time it takes to transfer the entire file, is several orders of magnitude greater than the end-to-end or round-trip network delay.

Why the elaborate breakdown of application types based on delay? As we can see from the preceding discussion, there are times when an application's requirement for delay is important to consider in the network architecture and design and other times when it is not as important. Whenever we can selectively ignore some applications and focus on others, the network architecture and design problems become more tractable.

In the next chapter we will discuss some of the time parameters associated with interactive burst and bulk applications.

2.5.2 Application Groups

We have so far used various examples of applications to convey application requirements. It is often useful to group applications with similar performance characteristics because it helps both in the mapping of performance characteristics and in gathering and understanding requirements. It has been useful to me to form groups for applications and keep adding to them as I encounter new applications. When trying to rapidly identify network requirements for a new customer, I have successfully used these groups to help identify requirements by comparing the new applications with those in groups I have already developed. This process is particularly useful if you have to do requirements analysis quickly or if you frequently have new customers.

With use of the requirements analysis process, the following application groups have been identified. There is some overlap between these groups, and this is not a complete set of groups. It is intended to illustrate how grouping works. You are encouraged to develop your own application groups as you apply the requirements analysis process to your networks.

  • Telemetry/command and control applications. Although the title may sound somewhat military, it actually describes a variety of applications in which data and command information are transmitted between remote devices and one or more control stations for command, control, tracking, and determination of status of the remote devices. A remote device may be a mundane one, such as an automated teller machine (ATM), sensors in the home, or remote computer, or esoteric devices, such as remotely piloted vehicles (RPVs), spacecraft, or commercial aircraft. Telemetry/command and control applications can be characterized as having realtime and/or interactive delay and are often considered mission-critical.

  • Visualization applications. This group ranges from 2D viewing of objects to 3D and virtual reality viewing, immersion, and manipulation of objects. Visualization may be of a numerical simulation or of experimental data. Examples include visualizations of fluid flow fields around various objects (e.g., weather modeling, aeronautics, medicine); to medical, biomedical, and molecular simulations; to commercial and military gaming simulations. Visualization applications can often be characterized as rate-critical and interactive-burst.

  • Distributed-computing applications. Applications in this group may range from having the computing devices sharing the same local bus (as in parallel computing) to being co-located at the same LAN (as in a computing cluster), to being distributed across LAN, MAN, and WAN boundaries (as in grid computing). The degree of distribution or parallelism in the computing is also determined by the granularity of the task and the degree of coupling between the computing devices. An example of distributed computing is in making use of desktop computers in the corporate environment late at night, when they are usually idle, by coupling their computing capability to accomplish large tasks normally done on a mainframe. Distributed-computing applications can be characterized as realtime or interactive burst.

  • Web development, access, and use applications. Applications in this group are the current interactive equivalents of the traditional remote device and information access utilities telnet and FTP. Web access and use involve accessing remote devices and downloading and/or uploading information. This is done with the aid of graphic interfaces. Typically, Web sessions are interactive, and the amounts of information are small relative to the other application groups (with the possible exception of telemetry/command and control). This group of applications is generally considered interactive—a mix of interactive-burst and interactive bulk.

  • Bulk data transport applications. When the amounts of information desired are relatively large and the sessions are less interactive (or asynchronous), applications can optimize the data transfer rate at the expense of interactivity. The traditional example of this is FTP, and currently more effective applications such as mftp and arcp are available. For more information on mftp and arcp, see www.nas.nasa.gov. These applications generally do not have high performance requirements.

  • Tele*service applications. This group describes the applications that provide a subset of voice, video, and data together to be delivered concurrently to groups of people at various locations. Examples include teleconferencing, telemedicine, and teleseminars (thus the tele*). The multicast backbone of the Internet is an example of network support for this application group. Tele*service applications can be characterized as having interactive and real-time delay and are often considered rate-critical and mission-critical.

  • Operations, administration, maintenance, and provisioning (OAM&P) applications. System OAM&P applications are required for the proper functioning and operation of the network. Examples include domain name service (DNS), mail services/SMTP, news services/NNTP, address resolution service, network monitoring and management, network security, and systems accounting. These applications are often considered mission-critical and interactive.

  • Client-server applications. This group includes applications whose traffic flows behave in a client-server fashion, such as enterprise resource planning (ERP), supply chain management (SCM), and customer relationship management (CRM) tools. We will discuss traffic flows and client-server flow behavior in detail in Chapter 4. These applications are often mission-critical and interactive.

You may be able to apply more application groups to your networks. If you develop requirements for multiple networks, you will be able to expand upon or modify this list to meet your analysis needs.

2.5.3 Application Locations

Along with typing and grouping applications, it is often useful to determine where an application applies in your (or your customer's) environment. There are usually some applications that apply everywhere, which everyone uses and that reside on almost all devices (e.g., servers, desktops, laptops). However, there are often applications that apply to particular users, user groups, servers, floors within a building, or buildings. When possible, identifying such applications and where they apply will help you in mapping traffic flows during the flow analysis process.

An example of an applications map, or drawing of where applications apply, is shown in Figure 2.6. In this figure of a campus environment, there are three sets of buildings, shown in gray. The location where each application applies is outlined. This is an estimate of the probable locations for applications in an environment and is the first step toward providing location information in the requirements analysis. In some cases, all applications will apply everywhere. In other cases, we will not be able to determine where some applications apply. Whenever such information is available, however, mapping that information will help us in the requirements and flow analyses.

Click To expand
Figure 2.6: Example applications map.

Application types, their performance requirements, their locations, and application groups form the interface between the application component and the rest of the system.


2.6 Device Requirements

We now turn to the requirements of devices that the network will support, particularly the types of devices, their performance characteristics, and location information. As we will see, this information will build on the user and application requirements from the last sections to begin to provide a comprehensive picture of system needs. The relationship of the device component with the rest of the system is shown in Figure 2.7.

Click To expand
Figure 2.7: Types of device requirements.

2.6.1 Device Types

Devices can be grouped into three categories: generic computing devices, servers, and specialized devices. Generic computing devices are the desktop and laptop computers that most users have. This group also includes handheld devices. Popular examples include various forms of Windows-based PCs, laptops and handheld devices, MACs, and LINUX-based workstations and PCs. These are the hosts that form the access points into the network and typically service a single user. Their requirements are important from an end-to-end perspective, for they provide the interface between applications and the network. Their requirements are also important in developing a template for devices from user groups or all users of the network. These end devices also tend to be overlooked, a form of "black box" that networks are connected to and applications run on, but are otherwise somewhat ignored.

A lack of understanding of end devices has led to what is known as the "last foot" problem in system performance. This is a modification of the "last mile" problem, which was the difficulty in getting infrastructure, networking, and services into a campus or building. The "last foot" problem is getting services and performance from the device's network interface through the device to its applications and users. This is discussed in detail later in this section.

Typically, there are many generic computing devices in a system, and it would be quite difficult to list, describe, and graph each individual device. Therefore, developing a template, or standard description, for one or more "standard" devices in the environment can be useful. Such a description might include device type, network interface, configuration, performance, and applications resident. Figure 2.8 shows an example of a template.

Device Type | NIC Type | Processor | OS | Applications
Low-End PC | 10M Ethernet | Pentium I | Win95/98/ 2000 | Word, PP, Finance
High-End PC | 10/100M Ethernet | Pentium III/IV | WinPro | Word, PP, DB, Graphics
Generic PC | 10/100M Ethernet | Pentium | Win95/98/ 2000/XP | Word, PP, DB, Graphics
Workstation | 10/100M Ethernet | AMD | LINUX | DB, Graphic, CAD, SC
Laptop | 56 Kb Modem | AMD | Win XP | Word, PP, Others
PP—Powerpoint DB—Database |  |  | CAD—Computer-Aided Drawing SC—Scientific SW

Figure 2.8: Example template for device descriptions.

Servers are computing devices that provide a service to one or more users (i.e., clients). They are typically more powerful, in terms of memory, processing, networking, and peripherals, than users' desktop or laptop devices. Examples of servers include compute servers, storage servers (also known as mass storage or archival systems), and application servers. Server requirements are important in that they may affect a large number of users. As such, their requirements warrant more attention on a per-device basis than generic computing devices.

Servers also have requirements for "last foot" performance, as well as requirements specific to its server role. A server's functions can often be streamlined to support this server role, which in turn may affect the system. For example, a server may be designed to support high-performance, predictable access to a large number of users. The cumulative effect of users' access to this server on the network must be considered. Servers have an impact on the traffic flows within the system, which will be examined in the chapters on flow analysis.

Specialized devices are devices that provide specific functions to their users. A parallel computer supporting a large database search engine may be considered either a server or specialized device, whereas a video camera on the network would be considered a specialized device. Specialized devices generally do not support direct access to user applications but rather gather, produce, or process information to be sent to users. Examples of specialized devices include supercomputers, parallel or distributed-computing systems, data-gathering and data-processing systems, medical devices, networked cameras or tools, and handheld devices.

Specialized devices tend to be location dependent. This is significant, for although, in most environments, generic computing devices and servers are becoming location independent, specialized devices often retain their location dependencies. This is generally the case; however, there are times when specialized devices are location independent and servers or generic devices are location dependent. As we will see in gathering requirements, it is important to know and understand the environment that we are analyzing, in part to understand any location dependencies of its devices. Specialized devices are often location dependent because of cost. A wind tunnel that provides flow information for car manufacturers is large, stationary, and expensive, making it difficult to replicate. If a network is being built to support this wind tunnel facility, located in Dearborn, Michigan, then the network has to be architected with access to Dearborn, Michigan, in mind, in addition to the performance and location requirements of the wind tunnel. Likewise, if a network was being built to provide remote access to medical devices (e.g., computed tomography [CT] scanners) for doctors, then the locations of these devices will become access requirements for the system. This is illustrated in Figure 2.9.

Click To expand
Figure 2.9: Specialized devices.

Although wind tunnels and CT scanners are very specialized (and in the case of wind tunnels, fairly rare) devices, this concept can be expanded to more common devices, such as ATMs, traffic sensors, and even stoplights. Also consider location-specific information—from libraries, universities, government centers, or medical centers. Much of this information is also closely tied to its location.

2.6.2 Performance Characteristics

The "last foot" problem introduced earlier focuses on the performance of various components of the device: hardware, firmware, and software that provide the glue between users and applications and the rest of the system.

For many environments, it may be difficult to determine or measure the performance characteristics of its devices. Components within a device are proprietary, and performance information about them can be sketchy or unavailable. Software and firmware driving the device, such as the operating system (OS), device drivers, application programming interface (API), and so forth, are complex. Therefore, when possible, determining this information for a "standard" device and creating a template is a practical solution. Taking the time to research or test one or a few devices and then applying this information in a template can save a lot of time and still be useful as a first-order approximation of device performance.

Note that device problems are often misinterpreted as network problems. Therefore, ignoring device requirements can compromise the network architecture and design. As we will see in the design process, identifying any issues with devices that will be supported by the network can make the design process easier, with more deterministic results.

A simple, general diagram of a device is presented in Figure 2.10. The performance of each of these components affects the overall performance of the device. As examples, disk drive seek times; memory access times; and the effectiveness of driver, OS, or API software will all affect the ability of the device to process information to and from the network.

Click To expand
Figure 2.10: Device components.

By looking at each of these components as integral to the overall performance of the device (and of the system), we are applying the end-to-end perspective within the device—the host in effect becomes a microcosm of the system. What we are looking for in performance characteristics include:

  • Storage performance, that is, flash, disk drive, or tape performance

  • Processor (CPU) performance

  • Memory performance (access times)

  • Bus performance (bus capacity and arbitration efficiency)

  • OS performance (effectiveness of the protocol stack and APIs, e.g., the number of memory copies in the protocol stack or the cost of execution of a given OS on a particular processor)

  • Device driver performance

Information about any of these components can be helpful in estimating the overall performance of a device or in identifying any limiting factors in device performance. For example, testing representative devices may result in finding that their network interfaces need to be upgraded (e.g., from 10 Mb/s Ethernet to 10/100 Mb/s Ethernet), that disk drives need to be replaced, or that an OS upgrade need to be performed. Although trying to understand the performance implications of each component of each device type can be time consuming, even a simple and quick attempt at developing device performance requirements can help ensure that there are no obvious dramatic performance bottlenecks at the device. Understanding at the device component can help you recognize such bottlenecks early in the analysis process.

2.6.3 Device Locations

Knowing the locations of existing or expected generic computing devices, servers, and specialized devices can be helpful in determining the relationships between users, applications, and networks. It can also be the start toward determining traffic flow characteristics for the system.

Location information helps determine the relationships between components of the system. Coupled with the types and performance requirements of devices, servers, and specialized devices, this information gives us insight on what the relative concentrations of users and devices should be, their placement, and the level of networking needed.

In Figure 2.11, an environment of three campuses is shown (buildings are shown in gray). Generic computing, servers, and specialized devices are shown for each building. Instead of showing each user desktop device, a total for each building is shown. The number of each server is shown as well.

Click To expand
Figure 2.11: Device locations.

Location information also helps us determine the traffic flow characteristics for the system. In Chapter 4 we will discuss flow models that describe how traffic flows within the system based on the relationships between users, applications, and devices, derived partially from location information about these components.

Networks where location information is particularly important are in the outsourcing of system components or functions; in the consolidation of organizations, system components, or functions; and in the relocation of system components or functions within an organization.

An example of how this information can be used is in the outsourcing or relocating of computer resources. Outsourcing may be accomplished by having the outsourcing agent operate, administer, maintain, and provision (OAM&P) the resources at the customer site or by removing the resources from the customer site and having the outsourcing agent provide the resources as well as the OAM&P. When the outsourcing agent provides the computing resources, knowing where the resources are to be relocated will be important in determining the flow models and level of networking needed. The outsourcing agent may choose a location that is optimized toward the administration of the computing resources, yet degrades the overall performance of the system. If a customer's computing resources are accessed via Fast or Gigabit Ethernet (GigE) and are then moved away from the customer into a WAN environment, either the access costs to those resources will rise (by requiring high-speed WAN connections) or the performance will degrade. In some cases, moving the resource from a LAN to a WAN environment may result in some applications being rendered unusable.

When the locations of system components change, it is important to evaluate or reevaluate the requirements of the system to determine whether service requirements (both performance and functional) have changed as well. Figure 2.11 illustrates that there are often location dependencies between applications and devices and that these dependencies need to be identified as part of the device requirements.

For example, if a LAN application that has a requirement for 100-ms round-trip delay is applied to a WAN with a round-trip delay characteristic of 200 ms, the network architecture/design and applications' or users' expectations will have to be modified to support the new network.

The interface between the device component and the rest of the system consists of the types of devices, their location dependencies, and their performance characteristics.


2.7 Network Requirements

Figure 2.12 shows the relationship of the device component with the rest of the system.

Click To expand
Figure 2.12: Types of network requirements.

For the network component, requirements for a network architecture/design must consider the requirements, services, and characteristics of any existing networks that will be incorporated into, or interface with, the new network.

2.7.1 Existing Networks and Migration

Most network architectures/designs today need to incorporate existing networks. Few networks today are built entirely from scratch. This includes system upgrades, such as adding a new application to the system, migrating to a new or different technology or protocol, or upgrading the network infrastructure, and the expansion or reduction of a system's size or scope. Sometimes the network architecture and design must accommodate any dependencies and constraints imposed by the existing network. Examples include:

  • Scaling dependencies. The existing network can affect how the planned network will scale. For example, how will the addition of the new network to the existing network change the size and scope of the system? Will the change be dramatic, as in growing from a LAN to a WAN, or will the change be within the LAN/MAN/WAN boundaries of the existing network?

  • Location dependencies. Depending on how the new networks interface with or incorporate the existing network or how the network modifications are done, the locations and/or concentrations of other components of the system are likely to change. This will show up when we develop flows later in the analysis process.

  • Performance constraints. The overall performance of the system will be affected by our architecture and design for the expected network (or network modification), how it interacts with the existing network, and its performance levels. Since the performance of the existing network will affect overall system performance, its performance characteristics should be integrated into the performance requirements of the planned network. Since the existing network is already in place, it is usually possible to measure the performance of this network. Thus, while the performance of the expected network is based on a best estimate, the performance of the existing network (and potential performance impacts) can be better understood.

  • Network, system, and support service dependencies. These include network addressing strategies, security, choices, and configurations of routing protocols and naming strategies, whereas support services include system-wide security, accounting, and monitoring and management. Current and planned requirements for each of these should be considered.

  • Interoperability dependencies. Interoperability dependencies between existing and planned networks occur at boundaries between the networks, usually where different technologies or media are used. In addition, by taking an end-to-end perspective on the design, the boundaries between existing and planned networks are points where service information and performance guarantees need to be translated, or they will be lost. Requirements should include the technologies and media of the existing network and any performance and/or functional requirements from the existing network.

  • Network obsolescence. Even though there may be parts of the existing network that will be integrated into the planned network, these parts, including network devices, protocols, and software, may become obsolete during the life cycle of your new network. When possible, you should note that parts of the network that will be integrated into the planned network, yet are near the end of their usefulness, will need to be transitioned out of the planned network.

In addition, requirements for the users, applications, and devices of the existing network must be considered as part of the system being built and their requirements analysis done along with the analysis for new parts of the system.

2.7.2 Network Management and Security

Throughout the architecture and design processes we will discuss network management and security, so it will be useful to briefly outline their requirements here, as a start toward considering them in the architecture and design. It is likely that our analysis of network management and security later in the architecture and design processes will generate new requirements or modify some that we develop here. At this point in the analysis process, we want to think in general terms about how we may accomplish network management and security in the new network.

As we will see in the architecture and design processes, there are four categories of network management tasks:

  • Monitoring for event notification

  • Monitoring for metrics and planning

  • Configuring the network

  • Troubleshooting

Monitoring is obtaining values for network management parameters from network devices (e.g., routers, hubs, switches) of the system, processing the data, displaying some or all of the data to network operators, and archiving the data. Monitoring for event notification involves taking a frequent snapshot of the network in order to understand the current state of the network and to help in isolating and solving network problems. If the data are collected for a long-term analysis of network performance, the monitoring is for metrics and capacity, RMA, and/or delay engineering. Network configuration and troubleshooting are more specialized tasks that are modifications of event notification, metrics, and planning.

In monitoring, we want to develop a set of characteristics that we will use for event monitoring and metrics and planning. These characteristics may be specific to each type of network device, which will be better understood later in the architecture and design processes. We will also consider the facilities for accessing these characteristics, which will include network management protocols, end-to-end monitoring tools, and direct access methods.

Some architectural issues with network management include determining the paths that the management data will take, as well as the hierarchy in management data flows. Management data can be in the path of the users' network traffic (in-band) or may take a different path (out-of-band). For the pros and cons of in-band versus out-of-band management, see Chapter 7. Management data flows can be hierarchical, indicating separate components of and locations for the management system, or flat, indicating that the management system is in a single device.

As with the other components of this chapter, the performance characteristics of network management also need to be considered. At this point, we can start to list some potential network management requirements:

  • Monitoring methods

  • Instrumentation methods (these include the network management protocols [SNMPv3, CMIP, RMON], parameter lists [MIBs], monitoring tools, and access methods)

  • Sets of characteristics for monitoring

  • In-band versus out-of-band monitoring

  • Centralized versus distributed monitoring

  • Performance requirements

In preparation for developing security requirements for our network, we first need to determine security requirements. We will perform a risk analysis for our existing network and planned network to gather information about current security and requirements for new security features. The risk analysis is often structured as a list of questions about the existing network, problems experienced, and network security strengths and weaknesses. It also often contains a risk assessment matrix, which contains potential security problems, system components that need to be protected, and perceived likelihood and severity of attacks.

Figure 2.13 shows an example of a security risk assessment for a specific organization. In this example, a risk analysis was performed as part of the requirements analysis, and the risk matrix shown was completed with the appropriate values.

Effect/ Probability | User Devices | Servers | Network | Software | Services | Data
Unauthorized Access | B/A | B/B | C/B | A/B | B/C | A/B
Unauthorized Disclosure | B/C | B/B | C/C | A/B | B/C | A/B
Denial of Service | B/B | B/B | B/B | B/B | B/B | D/D
Theft | A/D | B/D | B/D | A/B | C/C | A/B
Corruption | A/C | B/C | C/C | A/B | D/D | A/B
Viruses | B/B | B/B | B/B | B/B | B/C | D/D
Physical Damage | A/D | B/C | C/C | D/D | D/D | D/D
Effect: |  |  | Probability: |  |  |
A: Destructive |  | C: Disruptive |  | A: Certain | C: Likely |
B: Disabling |  | D: No Impact |  | B: Unlikely | D: Impossible |

Figure 2.13: Security risk assessment.

Security requirements and the results of the risk analysis will be used to develop a security plan and define security policies for the network.


2.8 Other Requirements

There are other requirements that apply across all of the components of the system, such as financial and enterprise requirements. There are likely to be other such requirements for your network, and they would be included here.

2.8.1 Supplemental Performance Requirements

In an ideal world, components perform according to specification all the time for the life of the system. Reality is often much less tidy. Couple that with the fact that human beings operate and maintain the systems we build and that their skills, quality, and morale are not always at maximum means that there are many things that can affect the performance of the network once it is installed. The real world intrudes on the network engineer when he or she looks beyond the point where the network is designed and implemented to the Initial Operational Capability (IOC), when the first segments are brought online in a production mode. They must consider that phase when finally the network implementation is complete and the system is in completely in the hands of the operators instead of the engineers to satisfy the customers and end users of this creation. Three characteristics of performance that reflect the customer's reality on our network design are operational suitability, supportability, and confidence. Operational suitability is a measure of how well our network design can be configured, monitored, and adjusted by the customer's operators. Supportability is a measure of how well the customer can keep the system performing, as designed, over the entire life of the system. Confidence is a measure of the ability of the network to deliver data without error or loss at the required throughput.

By identifying, documenting, and validating these constraints with the customer during the requirements analysis phase, the network engineer will ensure that the customer is prepared to understand the trade-offs between cost and performance and the time phasing of the total ownership costs and that the customer has a chance to influence these decisions. It also reduces the surprise factor when the owner has to actually operate the network. This also permits the customer to be prepared to identify when the network has exceeded the design capacity and commission an upgrade or service life extension or replacement. Customers who commission a network design to support 1000 connections should be aware that, when their need becomes 20,000 connections, they need an entirely different network; likewise, the need for higher reliability or substantially faster restoration of service during a fault may also warrant a new look at the architecture, components, and operating procedures that comprise the architecture/design.

These three factors must be taken into account when contracting for external services, such as MAN, WAN, or ISP connections; hardware; or maintenance services. The rate at which failures occur and the speed at which service is restored must be included in the specification and must be factors in the selection and award of third-party connectivity services.

These factors are often discounted or misunderstood by network engineers and by the customer themselves. Invariably, when customers are asked for their requirements, these factors are so fundamental in their way of thinking that they won't mention them unless asked. The network engineer, as part of the requirements process, must ensure that appropriate questions are asked and that the answers documented so that the design effort will properly factor them into the decisions about architecture, component selection, incorporation of third-party services (e.g., ISP), implementation planning, testing, and IOC.

Operational suitability, supportability, and confidence will be described in detail in Chapter 3.

2.8.2 Financial Requirements

An example of a system-wide requirement is to constrain expenditures to the level of funding that is available to implement the network, as funding for the network will be coupled to funding for other parts of the system, particularly devices. Funding is often associated with an overall cost limit, with one-time and recurring components. One-time costs are based on the actual planning and construction of the network and consist of network architecture, design, procurement, deployment, integration, testing, and all hardware/software components, as well as the initial installation or establishment of any services from service providers. Recurring costs are for tasks and items that are expected to occur or be replaced/upgraded on a periodic basis. This includes network OAM&P, costs from service providers, and provisions for modifications to the network. Time frames for recurring costs vary, driven by customer/end user, administrative, and management financial cycles and technology life cycles.

The level of funding is usually a constraint to the architecture and design; therefore, it is important to know what this level is as early in the analysis process as possible to avoid creating an architecture and design that are not economically feasible. In knowing funding constraints and the requirements for the network, we should be able to determine when an architecture/design that will meet its requirements will exceed available funding. In determining this early in the process, we can develop arguments for changing the level of funding, the requirements for the network, or both.

The financial requirements gathered during the analysis process will be combined with the users' affordability requirements to form a complete financial picture of the network. Later in this book we will consider funding constraints to the architecture and design and how these processes work to optimize the architecture and design to minimize costs. We will see that it is often beneficial to provide the customer with multiple prototype architectures and designs and well-defined functional and financial differences so that customers can help make clear choices about how they want to spend their money.

2.8.3 Enterprise Requirements

There may be times when you will have to consider requirements for the network that are commonly considered enterprise requirements, such as phone, fax, voice, and video. The integration of these types of requirements over the same transmission infrastructure as data is becoming common, and such enterprise requirements need to be considered as part of the overall requirements for the network.


2.9 The Requirements Specification and Map

As presented earlier in this chapter, the requirements specification is a document that lists and prioritizes the requirements gathered for your architecture and design, and the requirements map shows the location dependencies between applications and devices. We will now discuss these two documents in greater detail.

In going through the requirements analysis process, you will be gathering, deriving, and determining requirements from a variety of sources, including users, management, administration, and staff, as well as from documents about the existing network and its applications and devices. Some requirements will be taken verbatim, others will have to be derived from available information, and still others will have to be estimated.

When a list of requirements has been developed, you will need to determine which requirements are core, or fundamental, requirements; those requirements that may be considered desirable features for the network; requirements that may be implemented in a future release or upgrade of the network; those that are to be rejected; and those requirements that actually provide information about the system but that may not be actual requirements. You will also need to prioritize requirements to help determine where funds are spent, the order in which functions and features are applied, and where they are applied in the network.

A requirements specification lists all of these requirements and specifies where they were gathered from or how they were derived; reasons why requirements were considered core requirements, features, future requirements, rejected requirements, or informational requirements; and their priority levels.

Figure 2.14 shows a template for this information on a per-requirement basis.

Requirements Specification

ID/Name

Date

Type

Description

Gathered/Derived

Locations

Status

Priority

Figure 2.14: Template for the requirements specification.

The fields of this template are:

  • ID/name. This can be a number identifying the requirement in the order it was gathered or derived, or it can be the name of the requirement.

  • Date. This is the date when this requirement was developed.

  • Type. This represents the component that this requirement came from (user, application, device, network, or other).

  • Description. This is a listing of the details, if any, for that requirement. As part of this description, you may indicate whether the requirement is functional or performance in nature.

  • Gathered/derived. If the requirement was gathered, where it was gathered from is listed in this section. If the requirement was derived, how it was derived is listed here.

  • Locations. Where this requirement applies in the environment, if known, is noted here.

  • Status. This represents the current state of this requirement (core [or fundamental], feature, future requirement, rejected, or informational).

  • Priority. This is a number representing the priority level of this requirement within its status type.

Requirements may be managed and tracked through common word processing and spreadsheet software applications. The examples shown here were developed using a popular spreadsheet application. There are also software tools that are optimized for requirements tracking. Experience has shown that most of the common word processing and spreadsheet applications are sufficient for this task.

Example 2.1: Requirements Analysis for a Company LAN
Start example

A first attempt was made to gather requirements for a building LAN network. The results were:

  1. There are 150 users (60 engineers, 15 HR and Finance, 30 Manufacturing, 10 Management, 30 Sales/Marketing, 5 Other).

  2. Each area in the building must support Fast Ethernet connections to the backbone.

  3. Database, Visualization, Manufacturing, and Payroll applications are considered missioncritical for this company.

  4. Inventory application (INV1) for manufacturing requirements are not determined at this time.

  5. Database application (DB1) requires a minimum of 150 Kb/s per session.

  6. Engineering users have workstations with GigE NICs.

  7. Visualization application (VIS1) for finance requires up to 40 Mb/s capacity and 100-ms round-trip delay.

  8. Payroll application (PAY1) requires 100% uptime (while in operation) between finance and outside payroll company.

  9. Company must be kept secure from Internet attacks.

  10. Company requires a minimum of T1 access to Internet.

  11. Current network will be completely replaced, so there are no requirements from existing network.

  12. Other general applications include the following: mail, word processing, internal and external Web access.

The first attempt at a requirements specification would look like the Figure 2.15. The requirements are just listed in order; there are no status or priority levels assigned at this point. There are two exceptions to this—requirements 1 and 11 are shown with a status of informational (info). Also, when possible, the locations of these requirements are placed on the corresponding requirements map. The requirements map is shown in Figure 2.16.

Requirements Specification
ID/Name | Date | Type | Description | Gathered/Derived | Locations | Status | Priority
1 | 14Jan03 | User | User distribution is 60 engineers, 15 HR and Finance, 30 Manufacturing, 10 Management, 30 Sales/Marketing, 5 Other. | Gathered from Management | See Map | Info | TBD
2 | 12Jan03 | Network | Each area of the building must support Fast Ethernet connections to the backbone. Database, Visualization, Manufacturing, | Gathered from Management | All Bldgs | TBD | TBD
3 | 12Jan03 | Application | and Payroll applications are considered mission-critical for this company. More information needed. Inventory application (INV1) for | Gathered from Management | See Map | TBD | TBD
4 | 20Jan03 | Application | manufacturing requirements not determined at this time. | Gathered from Users (MAN) | See Map | TBD | TBD
5 | 14Jan03 | Application | Database application (DB1) requires a minimum of 150 Kb/s per session. | Gathered from Various Users | TBD | TBD | TBD
6 | 02Feb03 | Device | Engineering users have workstations with GigE NICs. Visualization application (VIS1) for finance | Gathered from Users (ENG) | See Map | TBD | TBD
7 | 20Jan03 | Application | requires up to 40 Mb/s capacity and 100-ms round-trip delay. Payroll application (PAY1) requires 100% | Derived from Application | See Map | TBD | TBD
8 | 11Feb03 | Application | uptime (while in operation) between finance and outside payroll company. | Gathered from Management | See Map | TBD | TBD
9 | 12Jan03 | Network | Company must be kept secure from Internet attacks. | Gathered from Management | TBD | TBD | TBD
10 | 02Feb03 | Network | Company requires a minimum of T1 access to Internet. | Gathered from Network Staff | See Map | TBD | TBD
11 | 02Feb03 | Network | Current network will be completely replaced, so there are no requirements from existing network. | Gathered from Network Staff | N/A | Info | TBD
12 | 20Jan03 | Application | Other general applications: mail, word processing, internal and external web access. More information needed. | Gathered from Network Staff | TBD | TBD | TBD

Figure 2.15: Beginning of requirements specification for Example 2.1.

Click To expand
Figure 2.16: Beginning of requirements map for Example 2.1.

End example


2.10 Conclusion

The requirements analysis process is about identifying, collecting, and evaluating requirements for the network. System requirements can be separated into components, where the choice of components is based on your environment and what you want to accomplish with the network architecture and design. In this chapter we considered components based on users, applications, devices, and networks. This is a starting point for grouping requirements. As you develop your own process for requirements analysis, you should determine how you would group requirements.

Requirements form the foundation upon which you develop the network architecture and design. Experience shows that the more effort you put into developing a good set of requirements and understanding the system that will be supported by this network, the better your network architecture and design will be.

By separating system requirements into components, the set of requirements becomes more workable. As we apply the processes, principles, and guidelines of the next chapter to each of these components, you will begin to see how understanding each component helps you build a picture of the overall system.

Having covered the concepts of requirements analysis, we are now ready to discuss the requirements analysis process in the next chapter. As you work through the next chapter, keep in mind the set of requirements we have identified in this chapter for each component of the system and how they can be combined into a requirements specification and requirements map.


2.11 Exercises

  1. Why is requirements analysis important to network architecture and design? Give three reasons.

  2. Categorize each of the following requirements as core (fundamental), feature, or informational.

    1. Network must support Fast Ethernet and GigE interfaces for all devices on the network.

    2. Network backbone should be upgradable in capacity to 10 Gb/s within 2 years of deployment.

    3. Finance department requires firewall protection to their server.

    4. Existing network consists of 10BaseT Ethernet and FDDI segments.

    5. Network personnel would like to be able to bill users for network service.

    6. Network core must not generate or terminate any user traffic.

    7. Network must support digital video traffic from remote video cameras and may additionally support sound from these cameras.

  3. Categorize each of the following requirements as user, application, device, or network.

    1. Database servers must run brand XYZ software.

    2. Teleconferencing requires at least 350 Kb/s capacity.

    3. Users must be able to submit print jobs of up to 25 MB in size.

    4. Each access network should be able to service 200 corporate users.

  4. Give an example of a requirement as it flows from user to application to device to network. Show how it becomes more technical at each component.

  5. Which of the following customer requirements could be categorized as mission-critical? As rate-critical? As real-time? As none of these? Give reasons for each choice.

    1. Processing telemetry data from a space shuttle launch and providing that data to mission control during launch. (Customer: NASA.)

    2. Processing requests from automated teller machines throughout a city. (Customer: bank.)

    3. Processing requests for Web pages from your servers. (Customer: Internet service provider).

  6. Give an example of a mission-critical application for each of these three environments: government, military, commercial. Why would each application be considered mission-critical?

  7. Section 2.5.1 describes several types of delay (real-time, interactive-burst, interactive-bulk, and asynchronous). Give examples of applications or traffic types that have each type of delay.

  8. Delay performance is increasingly important in support of user and application requirements. Describe why delay is important for the following applications:

    • Voice over IP (VoIP)

    • Nonbuffered (real-time) video or audio playback

    • Teleconferencing

  9. Based on the following application locations, develop an applications map using the template provided in Figure 2.17.

    Click To expand
    Figure 2.17: Template for Exercise 9.

    1. There is a distributed computing application between all compute servers.

    2. There is a data storage/access application between all compute servers and the storage servers in Main Engineering.

    3. There is a data migration application between Main Engineering, External Access Building, and Off-Site Data Archival.

  10. Which devices below can be considered generic computing devices? Servers? Specialized devices?

    1. An ATM machine

    2. Laptops running Linux OS

    3. IBM computing cluster of 128 PCs

    4. Sun Enterprise 450 database server

    5. Desktop PC running Windows 2000

  11. Add the following devices to the Applications Map developed in Problem 4.

    1. Compute servers are located in Buildings A, B, and C (1 server each), and 5 compute servers are located in Main Engineering.

    2. Storage servers are located in Main Engineering (2 servers), External Access Building (1 server), and at the Off-Site Data Archival location (1 server).

  12. List the top 10 applications that you expect to use in your (or your customer's) network or that you currently use in the existing network. List the actual or estimated performance characteristics for each application and try to place them into groups. You can also try to map them to the application groups listed in Section 2.5.2.


Chapter 3: Requirements Analysis: Process

The principles, guidelines, and procedures for requirements analysis are all part of the process model. This model, shown in Figure 3.1, outlines the major steps to gather, analyze, and develop requirements for your network.

Click To expand
Figure 3.1: Requirements analysis process.

3.1 Objectives

In this chapter you will learn about gathering and managing user, application, device, and network requirements. This includes setting and managing your customer's expectations about the network. You will learn about determining which variables to measure (service metrics) and how to make measurements. We will introduce modeling and simulation and discuss how they and other approximation techniques can be used to describe user and application behavior. You will learn about developing performance requirements for capacity; delay; and reliability, maintainability, and availability (RMA), including developing performance thresholds and limits. These will be useful in distinguishing between low-and high-performance requirements for your network. You will learn about general and environment-specific thresholds and limits and how to determine them. Some general thresholds are presented for your use. We will also discuss predictable and guaranteed performance requirements and their importance. Along with gathering and developing requirements, you will also learn about mapping requirements to geographic locations in preparation for traffic flow analysis.


3.2 Preparation

The material in this chapter builds on what was presented in Chapter 2. Therefore, the recommended sources of information listed in Chapter 2 also apply here.


3.3 Gathering and Listing Requirements

Service requirements are gathered and developed with initial conditions on the architecture and design, with input from users, administration, and management and then refined by applying our experience and knowledge about the analysis process. Some guidelines for quantifying requirements and developing thresholds and limits are given in this chapter, but first you must communicate with the users to gather their requirements, so we begin with a discussion of the initial conditions on the network.

3.3.1 Determining Initial Conditions

Initial conditions are the basis for the start of the analysis process. They help determine what you are designing toward, as well as the reasons for the architecture and design. Initial conditions consist of the type of network project, the scope of the architecture and design, initial architecture/design goals, and any outside forces acting on the network. Understanding these initial conditions is important because they will influence the network architecture and design and will often act as constraints on the architecture/design. The initial conditions could also be considered the current state of the existing network's architecture and design.

Before starting the process of gathering and analyzing requirements, you will likely have some notion of the initial conditions for the network project you are undertaking. For example, you will probably know the type of network project and the scope of the project. Some examples of these are as follows:

Type of Network Project

Scope of Network Project

  • New network

  • Modification of an existing network

  • Analysis of network problems

  • Outsourcing

  • Consolidation

  • Upgrade

  • Network size

  • Number of sites

  • Distance between sites

You may get your initial architecture/design goals from your customer, and part of this process is to validate those goals, possibly adding to, subtracting from, or modifying them during the process. Examples of such goals are as follows:

Initial Architecture/Design Goals

  • Upgrade technology/vendor

  • Improve performance to part or all of network

  • Support new users, applications, or devices

  • Solve perceived problems within system

  • Increase security

  • Support a new capability in system

Initially, you may not even be aware of outside forces, such as political, administrative, and financial, acting on the network unless you are part of the organization that is requesting the work. Thus, you are likely to have some, but not all, of the initial conditions for the network architecture/design.

Knowing the type and scope of the network project will help you focus your efforts. For example, replacing an old network with an entirely new one minimizes the number of constraints placed on the architecture/design by the existing network (except for possibly any existing external networks with which the new network will have to interface). This allows you to focus on achieving architectural/design goals for the new network. When the project is a modification or an upgrade of an existing network, you have more constraints from the existing network. The existing network will provide information about the current behavior of the network and what can be expected from the changes to the network. The existing network will constrain the architecture and design from the perspective of how to connect and interoperate with part or all of the entire existing network. Thus, the performance and functions of the existing network, along with the reasons for making changes to the network, are important initial conditions.

These conditions also apply when you are doing just the analysis of a network. In this case the network may not be functioning as planned, and you are trying to determine where the problems lie—in the architecture or in the design—or where the implementation varies from the architecture/design. If you are building a network to allow for outsourcing of resource operations, administration, maintenance, and provisioning (OAM&P) functions, then the initial conditions should include where the outsourcing will occur and the methods used by the outsourcing agent to provide OAM&P functions.

There are likely to be several constraints on the network architecture and design. By examining the initial conditions at the start of the analysis process, you stand a much better chance of understanding, removing, or working with these constraints. Common constraints on a network project include funding limitations; the need to work with various organizations or groups within an organization; organizational rules and regulations; time and schedule limitations; and technical constraints from existing users, applications, devices, networks, and management.

Funding limitations are critical to the network project. As we will see in the discussion of architecture and design processes, architecture/design choices are coupled to available funding. Disregarding funding in the analysis process will lead to architecture/design choices that will not be implemented, whereas considering this limitation up-front will help you make the most intelligent use of funding for the network. In this sense, funding limitations can be viewed as positive in that it forces the network architect to develop creative solutions to fit these funding limitations. It is also important to get as good a forecast for future funding as possible.

Organizational constraints, such as with whom you will be working or how groups interact, can become problems during the project. Knowing this in advance will allow you to prepare for this problem, usually by buffering yourself and the project from problem groups or individuals. Sometimes management can help with this type of problem.

There are often political constraints to the network project. Sometimes the technical solution to a network problem is constrained by the political desires of users, management, or staff. Such constraints, which are often illogical, can be the most daunting to work with. However troublesome they may seem, political constraints must be considered part of the network project. Depending on your position in the project, you may have options on how to deal with this type of constraint. As a consultant, you may be able to defer to management in dealing with politics or even refuse the project. As an employee, however, you are more likely to be an integral part of the organization, not easily separated from political issues.

Existing components in the system will often act as constraints. Users suffer from inertia, not wanting to change the ways in which they do their work. Applications written to be used locally on a device or for a particular network technology or protocol may have to be modified to function on the new network. Device interfaces and drivers may have to be changed or upgraded. Existing networks will bring their performance and functional limitations to the project. By knowing early in the process which parts of the existing system will be incorporated into or supported in the new network, you can determine which architectural/design choices will work and, just as important, which will not work.

Part of the initial conditions for your network project may be determining its performance target: multitier performance or single-tier performance (Figure 3.2). Multitier performance networks typically have one or a few applications, users/groups, and/or devices whose performance requirements are significantly greater than those of other components on that network. As a result there is a threshold between low-and high-performance requirements for this type of network. Typically, this set of high-performance requirements drives how and where performance is architected into the network.

Click To expand
Figure 3.2: Determining performance targets— single or multitier performance.

On the other hand, single-tier performance networks do not have a distinctive set of applications, users, or hosts that have significantly greater performance requirements for that network, so there is no threshold between low and high performance for this type of network. This is significant, for without a set of high-performance requirements to drive how and where performance is architected into the network, performance is architected to support everyone equally.

The performance target for the network as single tier or multitier is one of the fundamental concepts in this book, which we discuss in greater detail in the section on architecture and design processes. For many networks, you may need to consider both types in your architecture and design.

Determining the initial conditions for the network will lead you into the requirements analysis process. You will know some of the initial conditions, and you will have to learn others. As you start digging for answers, you will be gathering information for the analysis process.

3.3.2 Setting Customer Expectations

At this point in the analysis process it is important to begin to set customer expectations. This consists of:

  • A rapid, initial evaluation of the problem

  • Estimation of the resources and schedule

This is not intended to be an in-depth estimate but rather a quick evaluation to catch obvious problems. How quick the evaluation is depends, in part, on your role in the project. If you are a consultant or advisor, you may have to be very quick, on the order of hours or days. If you are the network architect/designer for the organization's network, you may have weeks to do the evaluation. In general, this evaluation can be done on the order of a few days. The intent is to inform customers, early in the process, when their expectations are unrealistic. This helps to realign the customer if necessary and avoids back loading of the project.

At times, you may find that customers' definition of the problem and their expectations are quite correct. Usually, however, these expectations need to be adjusted somewhat. In addition, there may be times when you find that customers' expectations and your expectations are so far apart that it is better not to continue on that project. It is better to find this out early in the project.

3.3.3 Working with Users

In working with users, your first inclination may be to think, "This takes too much time," "They are not cooperative," "They don't know what they want," and so on, but it is a vital—sometimes painful—part of the process. By initially spending time with users, you will gain a better understanding of their behavioral patterns and environment. For the end users, discussing your network plans with them will help them understand what you are trying to accomplish, building lines of personal communication that will be useful when you are installing, debugging, and operating the network later.

Although it can be challenging to communicate with users (including administration and management), there are some successful techniques that you can use:

  • Develop a survey to email, fax, or mail to users.

  • Follow up on the survey with one-on-one telephone calls or conference calls.

  • Follow up calls with face-to-face meetings with selected individuals or groups.

  • Conduct whiteboard sessions to elicit ideas from users.

  • Spend time with users while they work to better understand what they do and how they do it.

A key trade-off is the amount of time spent versus the quality of information gathered. Working with your users, administration, and management will pay off in another way: getting them to see that you are taking an active, systems approach in the network project, not just developing a network "in the dark." For the system to meet the needs of its users, users must be able to communicate these needs to you, the applications need to be designed to work across the network, and devices need to be chosen with the system in mind. The network is central to the system, so your role in bringing the systems approach to the users is important. In a sense, you are fostering support for the network, its architecture and design, and its role in the system.

Therefore, it is important not to take a hit-and-run approach, talking to the users only to get their requirements and not following up with them. By building relationships with the users, administration, and management, through discussing their requirements, advising them of results and anticipated actions, and informing them of progress with the network project, you are developing advocates for your network. This may be vital when you need to upgrade the network in the future or if you have to defend your architectural and design decisions.

While you gather requirements, look for warning signals, also known as "red flags." For example, warning signals occur when there is a lack of precision or clarity in requirements, such as the following:

  • Misuse of "real-time"

  • Availability as solely a percentage (99.99%)

  • "High performance" without verification

  • Highly variable, inconsistent requirements

  • Unrealistic expectations from the customer

When you encounter such warning signals, you should attempt, when possible, to clarify the meaning of the statement. Later in this chapter, we will discuss ways to clarify several red flags.

When you are gathering requirements and interacting with users, it is a good time to assess the opinion that users have of the current network, as well as that of the networking and operations staff.

3.3.4 Taking Performance Measurements

When possible, it is useful to measure performance levels of applications and devices that will be used in the planned network. This is often done either by testing applications and devices on a separate, controlled network (e.g., testbed network) or by measuring their performance levels on the existing network.

Building a small testbed network to measure application and device performance can serve multiple purposes. Since a testbed network is controlled, you can ensure that there is sufficient capacity available for your applications and devices. Thus, the network does not limit the performance of the applications and devices under testing. You will be able to measure peak performance, from which you can derive performance requirements for those applications and devices.

Measurements of peak application and device performance can be used to determine how much degradation in performance is experienced on the existing network. Such measurements become a validation of performance problems on the existing network.

Along with performance measurements, you can often capture all of the traffic from an application session through promiscuous monitoring of the network. This information is useful in characterizing and modeling application and user behaviors, discussed in Section 3.5. Tools that can help capture traffic include Sniffer, Ethereal, and Etherpeak.

If a testbed network cannot be built to measure performance, measurements can be made on the existing network (if permitted by management). You will be able to get performance data using this technique, but the existing network will limit application and device performance. This technique is still quite useful to capture traffic to characterize and model application and user behaviors. These two techniques are shown in Figure 3.3.

Click To expand
Figure 3.3: Measuring performance using a testbed and the existing network.

3.3.5 Tracking and Managing Requirements

Requirements also need to be tracked and managed. A list of requirements should be kept up-to-date in a location where everyone involved in the process has access to them. The Web is a great tool for posting, tracking, and managing requirements. You can use a number of methods to track and manage requirements; two of these are shown here. First is paragraph form, where a requirement is changed within its original paragraph. Example 3.1 shows a requirement managed in this form.

Example 3.1: A requirement for upgrades to network equipment is shown.
Start example

  • NR -1.0-102. All (technology A 3/7/2000) network equipment shall be capable of software (or firmware 4/1/2000) (deleted 4/17/2000) based upgardes to allow it to support changes to high speed (any 5/20/2000) data service features and functions.

This requirement has been changed as part of the analysis process. As you can see, changes were made at various times, reflecting the evolution of requirements as you talk with users, management, and staff. In this example, one requirement (for software-based upgrades) was changed on 4/1/2000 to include firmware-based upgrades, which was then deleted on 4/17/2000, restoring it to its original form. It is important to note that while a requirement evolves, the description of that requirement keeps all changes visible. In this example, you can tell what the original requirement was and how it has changed. Thus, if someone wants to make a change that was already attempted, he or she will know that beforehand.

End example

Another method to track and manage requirements is in tabular form. In this method, the requirement is kept in its original form and any changes to it are added to a table. Figure 3.4 shows how this is done, using the requirement from Example 3.1.

ID/Name | Date | Type | Description
NR -1.0-102 | 01Jan2000 | Original | All network equipment shall be capable of software-based upgrades to allow it to support changes to high-speed data service features and functions.
 | 07Mar2000 | Change | "All network equipment" changed to "Technology A."
 | 01Apr2000 | Change | "software based upgrades" changed to "software-or firmware-based upgrades."
 | 17Apr2000 | Deletion | Change of 01Apr2000 deleted.
 | 20May2000 | Change | "high-speed" changed to "any."

Figure 3.4: Requirements tracking and management in tabular form.

Other software tools, such as databases and spreadsheets, can be used for this process. The key point here is that requirements documents should be living documents, updated regularly to reflect the changing nature of the network and system.

As a list of what the system needs from the network architecture and design, these requirements will be used as the foundation for the rest of this book.

Initial conditions, constraints, and any assumptions about the environment of the network project should be included with the list of requirements. This helps determine the system components for which you need to get more information.

3.3.6 Mapping Location Information

As part of the analysis process, the locations of applications and devices will be mapped to show their relative physical locations. In Chapter 2, we introduced the concept of mapping applications and devices. While gathering requirements, note (when possible) the locations of servers and specialized devices and where specific applications are being used.

For example, Figure 3.5 shows an example of a metropolitan-area environment with devices and applications.

Click To expand
Figure 3.5: Example of a metropolitan-area map.


3.4 Developing Service Metrics

After gathering requirements for the network, the next step is to analyze these requirements so that you can distinguish between various performance levels in the network. We will develop and use performance thresholds and limits to distinguish between low and high performance and will also use performance characteristics to identify predictable and guaranteed performance levels. Performance thresholds, limits, and characteristics are measured in the system with service metrics.

Service metrics either are actual measurable quantities in the network or are derived from measured quantities. These service metrics are important; they are where "the rubber meets the road"—where requirements from all layers in the system are distilled into configurable and measurable quantities.

Recall from Chapter 2 that for a performance characteristic to be useful, it must be configurable, measurable, and verifiable within the network. This is particularly true when parts of the network are outside the control of the network administrator, for example, when a service provider is contracted to supply a service such as ATM or frame relay in the network or when parts of the network (or the entire network) are outsourced. In such cases, service metrics can be used to ensure that you are getting the service you are requesting (and paying for) from the service provider or outsourcing agent.

The types of service metrics you will use will depend on your design and the types of equipment (network devices) you implement in the network, but at this point in the analysis process, you can influence or require what will be measured in the network and (to some extent) how it will be measured.

Service metrics for RMA include:

  • Reliability, in terms of mean time between failures (MTBFs) and mean time between mission critical failures (MTBCFs)

  • Maintainability, in terms of mean time to repair (MTTR)

  • Availability, in terms of MTBF, MTBCF, and MTTR

Additional metrics can include uptime and downtime (as a percentage of total time), error and loss rates at various levels, such as packet error rate, bit error rate (BER), cell loss ratio (CLR), cell misinsertion ratio (CMR), frame and packet loss rates.

Service metrics for capacity include:

  • Data rates, in terms of peak data rate, sustained data rate, and minimum data rate

  • Data sizes, including burst sizes and durations

Service metrics for delay include:

  • End-to-end or round-trip delay

  • Latency

  • Delay variation

As configurable and measurable quantities in the network, service metrics can be described in terms of variables in network devices. There will also be mechanisms to configure and measure these variables. As we will see in Chapter 7, current mechanisms to configure and measure service metrics are with network management platforms that use the Simple Network Management Protocol (SNMP) and the Common Management Information Protocol (CMIP), which access variables described in management information bases (MIBs). MIBs describe generic and enterprise-specific management variables.

Examples of variables used as service metrics include:

  • Bytes in/out (per interface)

  • IP packets in/out (per interface)

  • Dropped Internet Control Message Protocol (ICMP) messages per unit time (per interface)

  • Service-level agreement (SLA) metrics (per user)

  • Capacity limit

  • Burst tolerance

  • Delay

  • Downtime

3.4.1 Measurement Tools

In addition to the management protocols and MIBs, we can use commonly available tools to help us measure service metrics. One such tool is the utility ping (Packet InterNet Groper) (available in TCP/IP releases), which roughly measures round-trip delays between selected sources and destinations in the network. Another tool is pathchar (available from ee.lbl.gov), which combines round-trip delay and per-link capacity measurements with path traces, such as with another popular utility traceroute. Another popular tool to analyze TCP traffic is TCPdump. There are also proprietary tools, enterprise-specific tools, and technology-specific tools that may be used in addition to those described.

For example, one method to monitor availability in the network is to use ping to estimate delay and packet loss (Figure 3.6). Ping tells us the approximate round-trip delay, as well as when ICMP echo packets (ping packets) are lost in the network or at the destination. Although not an exact method, it is fairly simple to set up and use and it provides an early warning mechanism for RMA problems.

Click To expand
Figure 3.6: Using ping and IP packet loss as service metrics for RMA.

When developing service metrics, we want to also try to determine where in the system we want to measure each metric, as well as potential mechanisms for measurement, as in Figure 3.7.

Service Metric |  | Where Metric Will Be Measured in System | Measurement Method
1 | LAN Delay | Between NM Device and Each Router in LAN | Ping
2 | Wan Delay 1 | Between NM Device and Local Router Interface to WAN | Ping
3 | WAN Delay 2 | Between NM Device and Remote Router Interface to WAN | Ping
3 | LAN Packet Loss | At Each Local Router | SNMP

Figure 3.7: Example service metrics.

3.4.2 Where to Apply Service Metrics

Where service metrics are applied is determined in part by what you plan to achieve from them (e.g., separating responsibilities). They are useful when trying to isolate and track problems in the network, especially when multiple groups are responsible for the network. For example, in Figure 3.6, the service metrics that are applied can also be used to separate responsibilities between an end-to-end provider, a WAN service provider, and other intermediate providers.


3.5 Characterizing Behavior

Characterizing behavior is representing how users and applications use the network; being able to characterize behavior helps you develop and understand their requirements. These representations range from very simple, such as estimating user session duration, number of active sessions, and data sizes, to more difficult, such as building complex and detailed models of user and application behavior. The goal of characterizing behavior for your network is to determine whether you can estimate network performance requirements through understanding how users and applications behave across the network.

In this section, we will examine some of the characteristics of users and applications that can be used to modify and better estimate network performance requirements. We will then apply these user and applications characteristics during the flow analysis process.

Types of behavior that we will examine include:

  • User behavior

  • Application behavior

  • Network behavior

3.5.1 Modeling and Simulation

Developing models or simulations of user, application, and network behavior is often useful in predicting, determining, or estimating requirements and data flows. Models can range from easy, simplistic, first-order approximations to highly complex and time consuming. What you get out of a model or simulation depends on the amount of time and effort you put into it.

Modeling and simulation are useful throughout the analysis process for characterizing user, application, and existing network behaviors. They are also useful during the architecture and design processes for understanding the temporal and spatial behaviors of traffic flows, as well as understanding equipment type, placement, configuration, and behavior under stress or failure.

Figure 3.8 shows an example of a simulation of a simple network. This example shows several devices connected to a shared media network and is based on a model developed to show performance characteristics of this network under stress.

Click To expand
Figure 3.8: Simulation of network performance behavior.

The displays in Figure 3.8 show the results of performance tests run on this simulation. Throughput, utilization, and delay are displayed graphically over time to represent the temporal behavior of the network.

Models and simulations can be developed by using proprietary or publicly available tools. One clear benefit from having such models is that, once developed, they can be used again and again to help tune the system for optimal performance. Thus, although such models and simulations may take time and effort to develop, their payback over time can be substantial.

3.5.2 User Behavior

In conjunction with identifying service metrics for your network, it will be useful to understand how users of the system will apply applications. Simple usage patterns can include user work times and durations, and for each application, the total number of users, the frequency at which a user is expected to have an application session running (usually as number of sessions per user, per day), how long an average application session will last (usually on the order of minutes), and an estimate of the expected number of simultaneous user sessions for that application.

The logic here is that we can develop a rule of thumb for scaling the expected performance of the network by examining user and application behavior. Figure 3.9 shows the characteristics of how a user uses an application. This is an example of a simple, first-order approximation of user and application behavior. In this figure, an application session is described by some common characteristics. First, the sessions are shown with the times that the session is active (as boxes). The size of each box indicates the duration of activity, and the number of boxes per unit time indicates the frequency of activity. Also shown in this figure is the number of simultaneous sessions that are active at any given point in time.

Click To expand
Figure 3.9: Characterization of user behavior.

Estimating the frequency and duration of application sessions and the number of simultaneous sessions will allow you to apply a modifier to the performance requirement for each application (or at least those applications you consider important enough to characterize). For example, if you can estimate the number of simultaneous sessions for an application, that estimate can be used as a multiplier for that application's capacity requirement. Similarly, if you know the duration of an application session, you can use that to help estimate the amount of time that service for that application will need to be configured within the network.

3.5.3 Application Behavior

It will also be useful to determine the behavior of application sessions. Along with user behavior, application behavior can help you to modify performance requirements to achieve a better estimate of which services and performance levels you will need for your network.

In characterizing application behavior, you want to consider the data sizes the application will be processing and passing across the network; the frequency and time duration for data to be passed across the network; any traffic flow characteristics you can get for the application, such as flow directions (e.g., from client to server); and any requirements for multicasting (including broadcasts).

In applying user and application behavior, you can go from a fairly simple approximation to a very complex model. For example, you can make some simplifying assumptions about usage patterns and application behavior. One simple model is to assume that only one session of an application will be active at any time. Another model is to apply statistical formulas to the usage pattern and application behavior. This can be quite successful when the application is well understood, such as with telephony applications.

Although you can attempt to characterize behavior for all users and applications for your network, you will usually get the greatest benefit by applying this analysis to the most important (mission-critical, rate-critical, real-time, interactive, high-performance) applications and their users, as their requirements typically drive the network architecture and design. Although characterizing usage patterns and application behavior can be both difficult and time consuming, you will find that doing so will greatly help your understanding of the system's requirements and how to apply them. However, you should be sure that you could afford the time and effort it will take. From personal experience, I have seen quick first-order approximations developed in days and complex, detailed models and simulations that have taken months to refine. However, many good approximations can be done on the order of a few weeks.


3.6 Developing RMA Requirements

Now we will expand on the performance requirements previously discussed, developing and quantifying requirements when possible. In this section, we will discuss two types of thresholds: general and environment specific. General thresholds are those that apply to most or all networks. They are rules of thumb that have been determined via experience to work in most environments. They are applied when there are no environment-specific thresholds to use. Environment-specific thresholds are determined for the environment of the current network project on which you are working. They are specific to that environment and typically are not applicable to other networks. These thresholds are useful in distinguishing between low and high performance for the network.

3.6.1 Reliability

Reliability is a statistical indicator of the frequency of failure of the network and its components and represents the unscheduled outages of service. A measure of reliability is in MTBCF, usually expressed in hours. A related measure is the MTBF, which considers all failures, regardless of their significance at the time of failure, and is a conservative approximation, useful in simple systems. MTBF can confuse the designer of a complex system. As systems become more complex and resource limitations restrict the degree of redundancy or the purchase of higher-reliability components, the use of MTBCF becomes more illuminating, although it does take more careful analysis, focusing on the system performance during specific mission scenarios. MTBF is computed as the inverse of the failure rate, which is estimated through testing or analysis in terms of failures per hours of operation. Criticality is factored in by considering the failure rates only of components that are critical to the mission. On the surface, reliability arithmetic is a little confusing; remember that calculations for reliability of systems are really performed by adding failure rates (failures per hour) of the components and then inverting the sum of the failure rates.

3.6.2 Maintainability

Maintainability is a statistical measure of the time to restore the system to fully operational status once it has experienced a fault. This is generally expressed as MTTR. Repairing a system failure consists of several stages: detection, isolation of the failure to a component that can be replaced, the time required to deliver the necessary parts to the location of the failed component (logistics time), and the time to replace the component, test it, and restore full service. MTTR usually assumes the logistics time is zero; this is an assumption, which is invalid if a component must be replaced to restore service but takes days to obtain.

3.6.3 Availability

Availability (also known as operational availability) is the relationship between the frequency of mission-critical failures and the time to restore service. This is defined as the MTBCF (or MTBF) divided by the sum of MTTR and MTBCF or MTBF. These relationships are shown in the following equation, where A is availability.

A = (MTBCF)/(MTBCF + MTTR) or A = (MTBF)/(MTBF + MTTR)

Some important considerations in evaluating availability are often overlooked. First, availability does not necessarily reflect the percentage of time that the system is operational: Scheduled maintenance is not taken into account in this calculation—only unscheduled maintenance is. This is significant because scheduled maintenance does not penalize the system since it can be performed when the components are not needed to perform the mission. The real concern is the surprise nature of system failures, which is reflected in availability.

One consequence is the ability to schedule preventive maintenance and replace frequently failing components at a higher interval than the failure rate, thereby increasing the reliability of the overall system. Another way to improve availability is to reduce the MTTR, either through redundancy or accelerated replacement capabilities. Several ways to achieve redundancy include installing automated switch-over capabilities for critical components so that they automatically switch to a redundant unit in milliseconds when a fault is detected; however, automatic switching is an expensive feature to add to these systems. If the pressure to restore service does not warrant this level of expense, rapid-replacement solutions can improve MTTR substantially over traditional troubleshooting and repair procedures: Hot spares that can be manually switched vastly accelerate the restoration of service, as does prepositioning spare components in proximity to the critical component's location. Other measures of availability include uptime, downtime, and error and loss rates.

Uptime and Downtime

A common measure of availability is in terms of percentage of uptime or downtime. For example, a request for proposal from a potential customer may state a required uptime of 99.999% (commonly known as "five nines"), but what does that really mean? What do the terms uptime and downtime really mean?

When availability is represented as the percentage of uptime or downtime, it is measured per week, month, or year, based on the total amount of time for that period. Uptime is when the system (applications, devices, networks) is available to the user (in this case, user may also be an application or device). Available, as we will see, can range in meaning from having basic connectivity to actually being able to run applications across the network. How this is described in the requirements analysis is important to how it will be measured and verified. Likewise, downtime can range from not being able to connect across the network to have connectivity, but with loss rates high enough (or capacity low enough) that applications will not function properly. Figure 3.10 shows some commonly used availability percentages (as percentage of uptime), ranging from 99% to 99.999%.

% Uptime | Amount of Allowed Downtime (Hours [h], Minutes [m], or Seconds [s] per Time Period)
 | Yearly | Monthly | Weekly | Daily
99% | 87.6 h | 7.3 h | 1.68 h | 14.4 m
99.9% | 8.76 h | 44 m | 10 m | 1.4 m
99.99% | 53 m | 4.4 m | 1 m | 8.6 s
99.999% | 5.3 m | 26.3 s | 6 s | 0.86 s

Figure 3.10: Uptime measured over different time periods.

Another way to view availability is by how much downtime can be tolerated per time period. The range shown in Figure 3.10, 99% to 99.999%, covers the majority of requested uptime requirements. At the low end of this range, 99% allows the system to be down quite a bit of time (more than 87 hours per year). This may be acceptable for testbeds or system prototypes, but it is unacceptable for most operational systems. When commercial service providers offer uptime that is at the low end of this range, this will need to be factored into the overall availability for the network.

An uptime level of 99.99% is closer to where most systems actually operate. At this level, 1 minute of downtime is allowed per week, which equates to a few transients per week, or one minor interruption per month (where a transient is a short-lived [on the order of seconds] network event, such as traffic being rerouted, or a period of congestion). Many networks that have had early uptime requirements below 99.99% are now relying on the network much more and are revising uptime requirements to 99.99% or greater.

At 99.999%, most systems begin to push their operational limits. This level of performance, which indicates that the network is highly relied on (e.g., for missioncritical applications), will have an impact on the network architecture and design in several areas, as will be discussed in later chapters.

Finally, an uptime beyond 99.999% approaches the current fringe of performance, where the effort and costs to support such a high degree of uptime can sky-rocket. There are even some applications that cannot tolerate any downtime while in session. For these types of applications, uptime is 100% while in session. An example of such an application is the remote control of an event (e.g., piloting a vehicle, performing an operation), where downtime may result in loss of the vehicle or possible loss of life (one of the criteria for a mission-critical application). In cases like this, however, the times of high availability are often known well in advance (scheduled) and can be planned for.

I should note at this point that many system outages are very brief in time (transients) and may not affect users or their applications. In some cases the users may not even know that a problem existed, as the outage may manifest itself merely as a pause in an application. Yet such events are part of the reliability estimate, especially in networks that have strict limits on reliability. Therefore, although a 10-minute weekly downtime (or 99.9% uptime) would be noticeable (e.g., application sessions dropping) if it occurred all at once, it could actually be a distribution of several 15-second transients, each of which results in applications stalling for several seconds.

With this information and the previous table of uptime estimates, we can present a general threshold for uptime. The general threshold for uptime, based on practical experience, is 99.99%. When this general threshold is applied, uptime requirements of less than 99.99% are considered low performance and uptime requirements of 99.99% or greater are considered high performance. Remember that this general threshold is used in the absence of any environment-specific thresholds that may be developed for your network as part of the requirements analysis process.

Measuring Uptime

In the previous section, we asked, "What does that (99.999% uptime) really mean?" In Chapter 1, requirements for services include that they be configurable, measurable, and verifiable within the system. This is one of the biggest problems with a requirement for percentage of uptime or downtime, but how can it be configured, measured, or verified?

In terms of measuring uptime, this question may be asked in three parts: When should it be measured (frequency), where should it be measured, and how should it be measured (service metrics)? First, let's consider the frequency of measurement. A problem with stating uptime solely as a percentage is that it does not relate a time factor. Consider, for example, a requirement for 99.99% uptime. Without a time factor, that can mean a downtime of 53 minutes per year, 4.4 minutes per month, or 1 minute per week. Without stating a time factor, there can be a single outage of up to 53 minutes. As long as that is the only outage during the year, this availability requirement may be met. Some networks can tolerate a cumulative downtime of 53 minutes per year but may not be able to handle a single downtime of that magnitude. There is a big difference between one large outage and several smaller outages.

Stating a time factor (frequency) along with uptime makes that requirement more valid. For networks that cannot tolerate large outages but can tolerate several small outages, 99.99% uptime measured weekly may make more sense than just 99.99% uptime. By stating "measured weekly," you are forcing the requirement that outages can be no larger than 1 minute total per week.

Next let's consider where uptime should be measured. Stating where uptime is measured is as important as stating its frequency. If nothing is said about where it is measured, the assumption is that a downtime anywhere in the network counts against overall uptime. For some networks, this may be the case and as such should be explicitly stated as a requirement. For many networks, however, uptime is more effective when it is selectively applied to parts of the network. For example, uptime to servers or specialized devices may be more important than general uptime across the network. If this is the case, it should be included as part of the performance requirement.

Figure 3.11 shows an example where uptime would apply everywhere in the network.

Click To expand
Figure 3.11: Uptime measured everywhere.

The loss of service to any device in this situation would count against overall uptime. In Figure 3.12, uptime has been refined to apply only between each user LAN and the server LAN. In this example, if service is lost between the user LANs, it would not count against an overall uptime requirement.

Click To expand
Figure 3.12: Uptime measured selectively.

In the aforementioned examples, we show a trade-off of being able to apply uptime everywhere versus having a precise and more achievable application of uptime. It is possible, however, to have both apply to the same network. You can apply one standard everywhere in the network and have another standard that is applied selectively.

Often, uptime is measured end-to-end, either between user devices (generic computing devices) or between networks. For example, it may be measured end-to-end between user networks, at network monitoring stations, or at network interfaces. Measurement points include the LAN/WAN interface, router entry/exit points, and at monitoring stations distributed throughout the network. Determining where to measure uptime is particularly important when service providers are embedded in the system or in demarcated services between well-defined areas of the network.

Finally, how you measure uptime is also important. As we will see later in this section, it may be measured in terms of lack of connectivity or as a loss rate (BER, cell loss rate, frame loss rate, or packet loss rates). The method you use to measure uptime will have an impact on how it can be configured within the network devices, as well as how it will be verified.

When developing requirements for uptime, you should keep in mind that some downtime on the network needs to be scheduled to allow for changes to be made to the network, hardware and software to be upgraded, or tests to be run. Scheduled downtime for maintenance should not count against the overall uptime of the network, and the amount of planned downtime (frequency and duration) should be included in your performance requirement.

Indeed, given the ways that we specify where, when, and how uptime is measured, we can actually have multiple uptime requirements in the network. For example, there may be a general requirement across the entire network, measured everywhere, and another, higher performance requirement, measured only between vital devices in the network.

Thus, a requirement for uptime might look something like this:

Network Uptime (see Figures 3.11 and 3.12 ):

  1. The 99.99% uptime requirement is measured weekly at every router interface and user device in the network.

  2. The 99.999% uptime requirement is measured weekly for access to the server farm network, measured at the router interface at the server farm, at the server network interface cards (NICs). The application ping will also be used to test connectivity between each user LAN and the server LAN.

  3. Note that these requirements do not apply to scheduled downtime periods for maintenance.

3.6.4 Thresholds and Limits

RMA requirements may include descriptions of thresholds and/or limits. RMA requirements are gathered and/or derived for each of the applications in the network from discussions with users of each application, as well as from documentation on the applications and testing of the applications on the existing network or on a testbed network. From the requirements, you can often determine environment-specific thresholds (or limits) on each application by plotting application performance levels. From this, you may determine what constitutes low-and high-performance RMA for your network. In the absence of environment-specific thresholds, you can use the general thresholds presented in this chapter.

In addition, check RMA guarantees (if any) for services and/or technologies that exist in the current network or that are likely to be in the planned network. For example, Pacific Bell's switched multimegabit data service (SMDS) has a stated availability, in terms of mean time between service outages or 3500 hours or more, with an MTTR of 3.5 hours or less. On the other hand, the Bellcore specification for SMDS calls for an availability of 99.9%. From our earlier discussion, we can see that both of these specifications describe similar availability characteristics, with the MTBCF/MTTR specification being more specific.

Some of these estimation techniques require knowledge of which technologies and/or services exist or are planned for the system. At this point in the process we really should not know which technologies and/or services we will be using for the network (since those are determined in the architecture and design processes), so these techniques may be used on the technologies and/or services that are in the current network or on a set of candidate technologies and/or services for the planned network. Later in the architecture and design processes, when we have chosen technologies and/or services for the network, we can apply the information gathered here for each of those technologies and/or services.

An example of a general thresholds for RMA is for uptime. Users normally expect the system to be operational as close to 100% of the time as possible. Uptime can get close to 100%, within a tenth, hundredth, or sometimes a thousandth of a percent, but with trade-offs of system complexity and cost. Earlier in this chapter, we described a general threshold for uptime, based on experience and observation, of 99.99%. In general, requirements for uptime that are 99.99% or greater are considered high performance, and those that are less than 99.99% are low performance. In addition, a general threshold of approximately 99.5% can be used to distinguish a low-performance requirement from that of prototypes and testbeds. These thresholds are shown in Figure 3.13.

Click To expand
Figure 3.13: Thresholds between testbed and low-and high-performance uptime.

Note that any environment-specific thresholds that are developed for your network would supersede these general thresholds.

Error or loss rate is used as a measurement of uptime. For example, for an uptime requirement of 99.99%, packet or cell loss can be used to measure this performance. For many applications, experience has shown that a 2% packet loss is sufficient to lose application sessions. This can be considered downtime and in fact is a more practical measurement and verification of uptime than attempts at mathematical representations.

Using a 2% loss threshold and measuring packet loss in the network, times when the packet loss is greater than 2% is counted as downtime. For 99.99% measured weekly, this is 1 minute per week that the network can have 2% or greater packet loss (see Section 3.9.3).

In addition to the aforementioned thresholds, performance and service guarantees will also be listed as application requirements. Determining uptime requirements is an iterative process. As users, devices, applications, and networks evolve, their requirements will need to be adjusted.


3.7 Developing Delay Requirements

For applications that have delay requirements, we will use the terms end-to-end delay, round-trip delay, and delay variation as measures of delay in the network.

We begin by introducing some useful general thresholds and limits for delay: interaction delay, human response time, and network propagation delay. These thresholds and limits are useful in helping to distinguish low-and high-performance delay requirements for your network.

Interaction delay (INTD) is an estimate of how long a user is willing to wait for a response from the system during an interactive session. Here a session is the time period during which an application is active. The INTD will depend on user behavior, the environment, and the types of applications being used. INTDs may range from hundreds of milliseconds to a minute or more. In general, a useful range is 10 to 30 seconds.

INTD is important when building a network targeted toward interactive applications. An INTD estimate is useful in characterizing applications that are loosely interactive—that is, those in which waiting to receive information is expected. This applies to transaction-processing applications, as well as Web, file transfer, and some database processing. For applications such as these, the user will notice some degree of delay, and INTD is an estimate of how long users are willing to wait. An upper limit to INTD is a measure of the tolerance level of users.

Human response time (HRT) is an estimate of the time threshold when users begin to perceive delays in the system. Thus, when the system response time is less than the HRT, users generally do not perceive any delay in the system. For delays greater than the HRT, users will notice the system delay. A good estimate of HRT, based on experience and observation, is approximately 100 ms. This is an important delay threshold for it distinguishes between when users will and will not notice a delay in the system. Note that when users notice a system delay, they become aware of the system. When architecting and designing a network in which one of the goals is to hide the system from the user, you should consider HRT a vital requirement for the system. An example of this is in grid computing, in which the system is abstracted from the users.

HRT is particularly important for highly interactive applications because wait times may not or should not be perceived by users of these applications. This is usually the case when the application supports an interactive environment for users, such as in visualization, virtual reality, and collaborative applications, but it may also apply to applications for which system delays greater than HRT result in loss of productivity.

Network propagation delay is an estimate of how long it takes for a signal to cross a physical medium or link, for example, the propagation delay across a DS3 link. This provides a lower limit to the end-to-end and round-trip network and system delays. Propagation delay is dependent on distance and technology. It is useful as a lower delay limit, for it tells you when an application may not work well across the network as a result of its network propagation delay requirement being more stringent than the actual or planned propagation delay of the network.

These delay thresholds and limits are shown in Figure 3.14. Any or all of these delay estimates may be applied to a network. For example, we can use HRT as a limit for all services, constraining the architecture and design to provide delay characteristics less than HRT for that network. Or we can choose a value for INTD that defines and limits interactive service. In all cases, network propagation delay will provide a lower limit for delay. Any of these delay estimates may also be used as guarantees on service.

Click To expand
Figure 3.14: Delay estimates for user requirements.

These delay estimates come from experience and are presented here for you to consider. You may disagree with their values or find other useful estimates for delay. You are encouraged to develop your own estimates or improve on those presented here. Since you know the network, system, and environment for your network project, you are in the best position to apply these estimates to your network. We can use the estimates for HRT and INTD to help us distinguish between interactive-burst and interactive-bulk applications. When both the responsiveness of the application (how frequently and quickly the application interacts with the user) and the end-to-end or round-trip delay (whichever is available to measure the system) are limited by one of these delay characteristics, we estimate that the application is interactive-burst or interactive-bulk.

In Figure 3.15, HRT and INTD are used as thresholds to separate interactive-burst and interactive-bulk applications. Between these two delay estimates, ranging from 100 ms to 10 to 30 seconds, is a gray area where the application could be considered either interactive-burst or interactive-bulk.

Click To expand
Figure 3.15: Performance regions for interactive-burst and interactive-bulk applications.

The use of INTD and HRT is probably the most straightforward way to distinguish between interactive-burst and interactive-bulk applications.

3.7.1 End-to-End and Round-Trip Delays

End-to-end and round-trip delays are composed of many sources of delay, including propagation, queuing, transmission, input/output, switching, and processing. Although it would be useful to be able to monitor and measure each source of delay, it is not practical for most networks. Therefore, totals such as end-to-end and round-trip delay are used. For many networks, especially IP networks, the round-trip delay is measured using various versions of the utility ping. Ping provides a useful, easily measured, and readily available form of round-trip delay.

Recall that we used HRT, INTD, and network propagation delay as thresholds and limits to distinguish between performance levels for delay requirements. They are based on combinations of the following:

  • Physical limits of the network—for example, the size of the network and the distances between applications, users, and/or devices

  • Device hardware and software performance

  • Network protocol performance

  • Application behavior at particular delay thresholds

  • User interaction with the system at particular delay thresholds

A guideline in developing delay requirements is to determine the limiting factor from the delay thresholds and limits. The limiting factor will be the ultimate delay bottleneck within the system. As limiting factors are found, they can often be reduced or eliminated, revealing the next limiting factor. This process is repeated until a limiting factor is found that cannot be reduced or eliminated or until system delay is at an acceptable level.

Given that physical limits on delay are absolute limits (the speeds of electromagnetic radiation through various media are well known), they may have an impact on or negate other delay thresholds. For example, if an application requires a round-trip delay of 80 ms to support an interactive virtual reality (VR) environment and the application session is being distributed between Los Angeles and Tokyo, the round-trip delay of the network (approximately 120 ms) will exceed the application delay requirement, regardless of the network architecture and design. Thus, either the application has to take into account the round-trip delay between Los Angeles and Tokyo, possibly by modifying the code, algorithms, or usage model, or the application sessions cannot be distributed between these sites. Knowing this early in the architecture process allows the application developers or network engineers to adapt to the physical limits of the network.

Now let's say that the distance of the aforementioned network is reduced and the physical limitation on the delay is now 10 ms (e.g., the network is now between Los Angeles and San Francisco). However, through testing the application on the current network, a round-trip delay of 100 ms is expected within the system (primarily because of the devices used). What can be done? Device hardware and software performance can be difficult to identify, understand, and improve. In architecting and designing a network, we need to try to consider each piece in the end-to-end path of communications (traffic flows), which may consist of a variety of devices. What can we look for that will reduce the likely sources of delay in the system, without an unreasonable amount of time, effort, and cost? Areas to check for sources of delay that can be modified or tuned include computer operating systems (OSs), network protocols, and device peripherals.

What we can look for in these areas are OSs that are notoriously slow and poorly written, protocols that are poorly implemented, and devices and/or peripherals that are mismatched or misconfigured. This type of information obviously will not come from the manufacturer but can often be found in mailing lists, newsgroups, independent testing, and academic research, all of which are increasingly available on the Internet. By doing some research, you can rapidly learn a lot about performance problems with devices. Make your own observations and analyses, and draw your own conclusions. As we will see later in this book, support services such as network management, routing, and security will also play a role in network delay.

Delay thresholds based on application behavior and user interaction are generally more flexible than physical or device delays. Recall that values for INTD and HRT were estimates (estimated range for INTD), so there is some flexibility to tailor them to your environment. Although in the previous example, the round-trip physical delay was the ultimate limit, when the distance of the network was reduced so the round-trip delay was on the order of 10 ms, the application behavior (interactive VR environment) with its 40-ms delay requirement may become the limiting factor. If this is acceptable to the users, then the delay estimates are (from our high-level view) optimized for that environment.

3.7.2 Delay Variation

Delay variation is often coupled with end-to-end or round-trip delay to give an overall delay performance requirement for applications that are sensitive to the interarrival time of information. Some examples of such applications are those that produce or use video, audio, and telemetry information. For delay variation coupled with end-to-end or round-trip delay, when no information is available about the delay variation requirement, a good rule of thumb is to use 1% to 2% of the end-to-end delay as the delay variation.

For example, an estimate for delay variation (in the absence of any known requirements), when the end-to-end delay is 40 ms, is approximately 400 to 800 s. This would be a rough approximation, however, and should be verified when possible.


3.8 Developing Capacity Requirements

In evaluating application capacity requirements, we want to consider applications that require large amounts of capacity and those that require a specific value (e.g., peak, minimum, sustained) or a range of capacities. When an application requires a large amount of capacity, it is important to know when the application has a real (measurable and verifiable) requirement for high capacity and when it (or the transport protocol it is using) will just attempt to use whatever capacity is available.

Applications that use TCP as their transport mechanism, without any additional conditions or modifications from the higher-layer protocols (or from the application itself), will receive performance levels based on the current state of the network (i.e., best-effort). This is done through communicating and adjusting TCP transmission parameters (across the TCP control channel between the two devices in the TCP session) throughout the TCP session to react to conditions of apparent congestion in the network.

3.8.1 Estimating Data Rates

Estimating a data (or maybe more accurately, information) rate is based on how much information you know about the transmission characteristics (e.g., traffic flow) of the application and how accurate the estimation needs to be. Data rates that are often used are peak data rate, sustained data rate, minimum data rate, or combinations of these. These data rates may be measured at one or more layers in the network (e.g., physical, data link, network, transport, session).

The data rates of all applications are bound by some limiting factor. This may be the application itself or it may be the line rate of the network interface on the device the application is running. Or it might be the performance level of a server the application uses. So the real question is where the limits are in the system for that application. If the application itself supports a very fast data rate (which can be determined by running the application on a test network), then you can go through a process of elimination to determine which component, on the device or somewhere else, is causing the performance bottleneck. In a sense, this is a local optimization of the network. In this case, you are doing it for a single application in a closed network environment.

Many applications rely on the transport protocol, such as TCP, to provide an "as fast as possible" data rate. We have an intuitive feel for some of these applications (e.g., file transfer protocol [FTP], telnet); for example, we can be fairly certain that a telnet session will not have a data rate of 100 Mb/s and that an FTP session should not run at 10 Kb/s if there is greater capacity available.

What we can do to estimate data rates for applications is consider their data sizes and estimated completion times. Data sizes and completion times either are based on what users may want or expect or may be measured on the existing network.

Taking an application that has nebulous capacity and delay characteristics, like Web access, we can estimate a data rate from user-and application-provided data sizes and completion times (e.g., INTD). We may ask a number of users for examples of pages they expect to access or information they would download, and how long they are willing to wait for each event. From this information, we could create entries in a table like the one shown in Figure 3.16. From estimates such as those in Figure 3.16, we can estimate upper and lower limits for an application's data rates or for an average rate.

Application | Average Completion Time (Seconds) | Average Data Size (Bytes)
Distributed Computing (Batch Mode) | 103 | 107
Web Transactions | 10 | 104
Database Entries/Queries | 2–5 | 103
Payroll Entries | 10 | 102
Teleconference | 103 | 105

Figure 3.16: Completion times and data sizes for selected applications.

For other applications, the characteristics of the data transfers may be better known, such as the sizes of the data sets being transferred and the frequency and duration of such transfers. This may apply to transaction-based applications, such as credit card processing, banking applications, and distributed computing.

Consider a remote interactive data-processing application that connects to retail stores and processes customer information, such as credit card entries. We can base an event (task) as the processing of single customer's credit card information. Then, the completion time of the task is on the order of INTD discussed earlier—approximately 10 to 30 seconds, although it may be expected by the users (store personnel) to be much smaller, say, on the order of 5 to 10 seconds, and the data size for each task is fairly small, on the order of 100 to 1000 bytes.

Another example is a computing environment in which multiple devices are sharing the processing for a task. At each iteration of the task, data are transferred between devices. Here we may know the frequency of data transfer, the size of each transfer (which may also be constant), and how much time is required to process the data (which may indicate how much time a transfer may take). A shared, multiprocessor computing network is shown in Figure 3.17.

Click To expand
Figure 3.17: Example of a shared, multiprocessor computing network.

For some applications, the capacity characteristics are well known and estimating a data rate can be relatively easy. Applications that involve voice and/or video usually have known capacity requirements. The rates of such applications are likely to be constant, so their peak and minimum data rates are the same or there will be a known range of values. For example, an MPEG-2 low-level constrained-parameter bitstream (CPB) will have a rate of 4 Mb/s, or a main-level CPB will have a rate between 15 and 20 Mb/s.

There are currently no general thresholds or limits on capacity to determine low-and high-performance capacity. It is not obvious why this should be so, except that RMA and delay have a direct impact on the user's perception of system performance, whereas capacity has a secondary impact through affecting RMA and delay. There will often be, however, environment-specific thresholds on capacity, determining low and high performance for that network.

Generic performance thresholds can be added to the performance envelope we developed in Chapter 1. These thresholds, as shown in Figure 3.18, are used to separate the envelope into low-and high-performance regions. This gives us a visual interpretation of the relative performance requirements for the network and can be used to relate performance requirements to management.

Click To expand
Figure 3.18: Performance envelope with generic thresholds.


3.9 Developing Supplemental Performance Requirements

Three supplemental performance requirements were introduced in Chapter 2: operational suitability, supportability, and confidence. These performance requirements are part of the overall set of operations and support elements shown in Figure 3.19. Operational suitability is a measure of how well the network design can be configured, monitored, and adjusted by the customer's operators. Supportability is a measure of how well the customer can keep the system performing, as designed, over the entire life of the system. Confidence is a measure of the ability of the network to deliver data without error or loss at the required throughput.

Operations and Support
Operations | Support
Management | Management
Personnel | Maintenance Support
Tools | Technical Documentation
Consumables | Storage
Transportation | Supply Support
Leasing | Modifications
Facilities |

Figure 3.19: Elements of operations and support.

3.9.1 Operational Suitability

Ensuring that your customer can operate the planned network is almost never an easy task and one that the customer never thinks about until asked. Two major factors influence the operational suitability: network architecture/design and the quality of the human operators.

It is possible to develop a network that cannot be operated consistently and effectively. Complex minute-to-minute adjustments can swamp even the most competent staff. The lack of any effective monitoring tools or control systems to integrate actions across geographically dispersed sites can transform the most advanced design into a dysfunctional mass of cable and computers and recriminations and lawsuits. Development of the network must consider network management that permits the operators to adjust the network and to reconfigure it when they need to. If they need to do it every few minutes, network management must be easy to operate and present the controls in an easily understood way.

An undersized operations staff can be quickly worn out and frustrated by a network that requires constant and precise tending. Components that never need adjustment except when they are installed do not need to clutter the integrated control console. System monitoring is essential to adjusting system performance by its operators; displays must be accessible and the data displayed using well-understood representations. Should there be a single (or redundant) operations console, or should the system be operated from any Web browser within the network? To what degree is automation incorporated to reduce the operators' workload or to improve the response to changing conditions over what a human can provide? Is system adjustment so infrequent that no integrated control system is required? These issues are discussed in detail in Chapter 7.

A Marine colonel who managed a major system development program kept a picture on his wall of the most pathetic, bedraggled Marine recruit he had ever seen. This Sad Sack was standing on an empty parade ground holding a bag of trash in one hand and a stick with a nail in the other to use to pick paper off the ground. The caption read, "Remember. No matter what you dream, what you plan, this man must execute." Operators are more essential than any technology to successful communications over a network.

In most cases a new network design is the result of obsolescence or an order-of-magnitude increase in performance requirements. These new components and tools are likely to be radically different than those currently in use by the customer, so the current staff is also likely to be obsolete or inadequately sized. It is almost always necessary to retrain or replace the operations staff during the transition period; it may also be necessary to radically expand that staff if a much larger scale network is required to meet the customer's growing needs for communications. Keep in mind that replacement of humans in the system is much more difficult than replacing routers with switches or multimode fiber with Category 6 copper cable.

These are activities that must be planned before the transition and implementation period and usually have a significant lead time, but they must be accomplished before the network achieves its initial operational capability (IOC). It is essential that the network engineer systematically uncover the customer's needs and constraints in these areas, document them, and then factor them into the design. These factors have a significant influence on the degree of automation that is incorporated into the design and the assumed skill level needed to operate the network.

Presenting this information during the design review ensures that the customer understands what it takes to operate the network and that any changes to the design (e.g., increased automation to compensate for a small staff) are made early in the process rather than cobbled onto the final product or into an endless cycle of change orders during delivery.

One of the key benefits to a skilled and motivated operations staff is their ability to apply the basic network architecture/design to meet new situations that were unforeseen during the development phase. Lacking this set of skills, the network engineer's design must be even more robust and have a high degree of automation to ensure that the system is protected from the operators. A set of operators who respect the documented procedures and understand the system architecture and how the components work together can be trusted to improvise when new situations occur, as they always do. A set of unskilled operators requires a system design that is constraining to ensure ongoing performance.

A common customer edict is that the new network be operated with the same personnel as the old network or that, as a minimum, the operations staff be no more expensive than the current staff. It is essential that the design engineer meet the operations staff to develop an opinion about their skill level ability to understand new technologies and to adopt new procedures and tools. There is a trade-off between system automation and workforce, with the trade-off being that lesser qualified operators can be used. Some operations personnel are unwilling or incapable of learning to operate the new systems, so new personnel must be brought in to perform these functions. Requirements for operator selection, qualification, and training (both initial and refresher) may seem burdensome but are absolutely necessary. If the requirement to retain the same staff is hard and fast, then system design using advanced components and architectures must take this into account.

Operational suitability requirements must be collected from interviews with the operators and owners. If new staff is going to be used, then interviews with people of approximately the same skill level should be substituted; these must be operators, not the design engineering team, which may not have the experience necessary to see how the system looks from the operator's point of view.

Articulating a concept of operations is very useful in defining the customer's needs, conveying the overall approach to the design team, and ensuring that the customer has fully conveyed his or her strategy to the designers. Such a document should be no more than 10 pages long and address the operator skill level and shift work organization, the tempo of operations, the degree to which the operator is expected to reconfigure the system and how it is done. Some additional questions to be considered during the requirements analysis process are as follows:

  • How is the operator going to monitor performance to ensure that he or she detects failures, faults, or outages before the customer does, or does the operator rely on the users to detect faults and report them?

  • How does the end user interact with the system and the operators, including reporting problems, and how are these reports tracked and responses provided? If multiple levels of quality of service are available, how does the end user request an increase or authorize a reduction in quality of service?

  • At which point does an operations problem transition into a maintenance action, and how does this occur so that it is not neglected?

  • How does the operations staff monitor system capacity and alert management to the need to expand capacity beyond the resources available to them? What types of time-averaged trend analysis will be performed to anticipate growth of demand?

3.9.2 Supportability

A key component of the customer's satisfaction with the network, as delivered, is the ability to maintain the high level of performance achieved on the day of delivery throughout the design life of the network. A relatively unsophisticated customer will recognize the poor quality of a design and implementation only when it is frequently out of service, whereas an experienced and knowledgeable customer will examine the design carefully before authorizing implementation and will want to know if it will persistently provide quality performance for its entire life cycle. He or she will also want to know what it takes to operate the design and what it takes to support continued operations. A sophisticated customer will understand the implications of an operations concept and a support concept and will respect the designer's commitment to ongoing performance after the implementation is complete and the engineers are paid.

Supportability is driven by five major factors: (1) the RMA characteristics of the architecture/design; (2) workforce, including training and staffing levels; (3) system procedures and technical documentation; (4) tools, both standard and special; and (5) spare and repair parts.

Two classes of maintenance need to be performed on the network after it is deployed: preventive and corrective. Eventually, the maintenance requirements are defined as the design is solidified. Requirements for maintenance, during this stage of the system definition, are generally qualitative in nature:

  • All components will be located where they can be maintained in place with a minimum of disruption to the system as a whole.

  • Spare parts will be supplied to ensure replacement of any component whose failure would jeopardize mission performance.

RMA

The first step in defining RMA requirements is to articulate a representative sample of mission scenarios in which the network is going to be used; these are documented in an anecdotal narrative that describes how the usage will occur, when, what is necessary for this mission to succeed, and how important it is to network users. This includes how often and the level of priority assigned to this mission.

For example, the network described in Section 2.6.3 may have users in one building who require access to data in another building that are necessary to pay employees; this data flow path is necessary only from 4 to 5 PM on Friday afternoon so that payroll can be accomplished locally over the weekend and employees paid on Monday morning. So, this becomes mission-critical during that period and as a fall-back position may continue until the local processing must start or the payroll will not be accomplished on Monday morning, resulting in disgruntled employees and all the unpleasantness that can bring. This path is not mission-critical on Monday afternoon and could therefore fail or be shut down for maintenance at that point, provided it doesn't interfere with other functions.

One possible design consideration is to include an automated system end-to-end test before the start of this critical period that would advise the operators that a system failure has occurred, which, if not corrected, could delay their paycheck for the next week. Many architectural and design features can be incorporated, but only if the architect/designer knows how the system is going to be used.

Based on the mission scenarios, reliability block diagrams (RBDs) can be constructed, for each mission, showing serial and parallel relationships between components and the performance of the mission. During the requirements analysis phase, these are at a very high level and reflect functions to accomplish the mission, rather than components to accomplish the mission. A sample RBD is presented in Figure 3.20.

Click To expand
Figure 3.20: Sample reliability block diagram.

Once a design is developed and the architectural details laid out, failure modes, effects, and criticality analysis (FMECA) can be conducted to identify the primary ways in which the system can fail to perform its mission. These can then lead the designer to establish detection modes that would reduce their occurrence or accelerate the restoration of service. A template for FMECA data is shown in Figure 3.21.

Click To expand
Figure 3.21: Template for FMECA data.

During the RMA analysis of the design, it is essential to remember that RMA is a tool to help the designer understand system performance so that he or she can make informed decisions.

Workforce

As with operational suitability, discussions of supportability often focus on keeping the existing workforce and/or budget the same. With the introduction of sophisticated and new technologies, this may present problems. Retraining or replacing the staff may be a strategy in the implementation that is required. Another approach is rebalancing maintenance to use contracted expert services in those areas in which the existing workforce lacks the skills. In some cases, it may make sense to outsource all maintenance, particularly when the network is a supporting function of the owner's primary line of business and he or she does not want to develop a highly skilled, expensive, internal workforce. During the requirements analysis phase, the principal objective is to get a clear picture of the customer's constraints on changing the workforce.

The personnel that will operate and maintain the network must be properly trained and possess the appropriate qualifications. One approach to defining requirements in this area is to survey the existing workforce's skills, depth, and formal training; document these features; and use them as the baseline for the new network maintenance workforce. Any changes needed then can be handled as engineering changes to the baseline requirements and the existing workforce.

Procedures and Documentation

In general, three classes of documentation are required to support the network. System and component technical documentation describes the characteristics, parts, and so on of the complete set of equipment that makes up the design. Maintenance procedures describe both the periodic preventive maintenance actions and their scheduled performance to keep the system running properly. Casualty procedures describe the abnormal (hopefully) procedures to follow when system faults occur to minimize damage to the system and to restore service as quickly as possible; prior planning for expected failure modes will do more to restore service quickly than any other investment during implementation.

Technical documentation is usually provided by the vendor of the components and is usually adequate. During implementation, the documentation should be inspected to ensure that spare and repair parts are identified so that the parts list is available if they need to be ordered quickly in response to a fault or failure. Technical documentation to describe the integration of network components is generally new material that the engineering team must generate as part of the testing, deployment, and integration of the new network.

Maintenance procedures must support both component-and system-level maintenance. This documentation must identify the frequency of and procedures for performing preventive maintenance, as well the procedures for reconfiguring the network to temporarily operate at a reduced capability while replacement components are swapped for overhaul and maintenance. Such procedures identify the tools and initial conditions required to start the procedure, testing to be performed before returning the system to a normal state, and indications that the maintenance has been performed properly or improperly.

Casualty procedures describe the planned actions for the operators to perform when a system fault occurs. These are broken down into immediate actions and supplemental actions. They are designed to place the system in a safe state and to operate it at reduced capability until the fault can be isolated and repaired with full service restored.

During the requirements analysis phase, the scope of each of these classes of documentation should be documented as a basic set of requirements.

Tools

The provisioning of common and special test equipment and tools is a consequence of the network architecture and design. At this stage, the requirements in this area represent possible constraints on the architecture and design. They should be stated in terms of the growth over the current set of tools that are possessed by the current maintenance staff. New tools should be acquired along with the components they are required to service instead of separately to ensure that they work properly with the planned network configuration.

Special test equipment, monitoring, and diagnostic software requirements should be defined during this phase in terms of their ability to improve response time to system performance issues, including failures and faults. This may represent a development effort or, as a minimum, an integration effort as the network is deployed. It would be reasonable at this point to specify the capability to detect system faults and performance degradation and to display status and key metrics at the operator's console or via a Web browser from a central server. Another requirement for consideration is the ability to monitor, reconfigure, or reset routing components using out-of-bandwidth connections, such as an analog line and a modem tied into the maintenance port on the network routing devices. This has an impact on which devices meet these requirements, and for a network with components at long distance from the operators, this may permit maintenance without physical visits.

Repair and Spare Parts

Requirements to be imposed on the spare and repair parts inventory at this stage are qualitative constraints, not a list of parts to be delivered. Some sample requirements that customers might define at this point include the following:

  • Spare and repair parts shall be stored in the network operations facility and cannot exceed, in volume, the space allocated, which is x cubic feet.

  • Initial spare and repair parts shall not exceed 15% of system acquisition costs.

  • Contract vehicles for replacement spare and repair parts shall be in place before the IOC.

Specific requirements for maintenance are generally driven by the network architecture and design and are documented in a maintenance plan, based on the design. Eventually, the spare and repair parts provisioning is derived from the actual design and a maintenance analysis of the design.

Support Concept

Definition of support concept describes the way in which the network is supported. It may help articulate the customer constraints, and it helps identify alternative approaches to support that can be accommodated in the design.

A commonly accepted maintenance support concept is the three-tier model. At the local level, or the first tier, the operators can perform a set of minimal maintenance actions. They can monitor for component failure and isolate the problem. Since they are often on-site, or at least in proximity to the components, they can handle immediate actions for system faults or casualties and some supplemental actions, such as rerouting circuits or replacing certain line-replaceable units.

The second tier is an intermediate maintenance activity, which has the ability to repair some components or to provide a place for on-site repair by the factory service representatives, if they are working locally. This tier involves staffing with specialized skills and a limited set of equipment. This is often handled via service contracts with the vendor or a third party who is sufficiently local and therefore able to arrive onsite within a short time. The third tier is the factory service, which generally involves a contract for service and shipping the equipment back to a maintenance location for refurbishment or repair.

In the three-tier approach (Figure 3.22), the local operators simply identify the failed component, pull the line-replaceable unit containing it, and replace it to restore service. The failed local repair unit is then shipped to the second tier or even to the factory for repair or refurbishment. Documentation must be provided to the tier 1 workforce, describing how to pull and replace components, and they must have a limited set of tools and special equipment to accomplish these functions.

Level | Location | Who | Tools and Test Equipment | Corrective Maintenance | Preventive Maintenance
Organizational | Operations Sites | Operators | Common tools Operator consoles and controls Inexpensive special tools | Day-to-day monitoring Troubleshooting Fault isolation Replacing LRUs Reconfiguring system | Monitoring performance Minor on-site cleaning and adjustments Scheduled replacement of LRUs
Intermediate | On call to work onsite | Trained personnel whose primary role is maintenance | Special or expensive portable tools with limited use | On-site repair of offline equipment | Major on-site upgrades where shipment to factory is impractical Supplement operators
Depot | Vendor or factory | Vendor or factory personnel | Equipment to refurbish components | Overhaul and refurbishment | Scheduled overhaul or disassembly of LRUs

Figure 3.22: Three-tier maintenance structure.

The degree to which contracted services are used should also be addressed by the support concept.

Usually, at this stage of the requirements analysis, it is sufficient to document the current model for support and identify any changes that are likely to be required to support the new network.

3.9.3 Confidence

Confidence is a measure of the ability of the network to deliver data without error or loss at the required throughput. This can be estimated in terms of error and/or loss rates. Although error/loss rates are more commonly used at the network-device level, we can also make some general performance estimates from them. As with other performance estimates, the ability to estimate uptime is strongly based on the ability to measure it within the system. For these rates, this is done:

  • Per link or circuit, such as for BERs

  • Between network devices, such as CLR or CMR between ATM switches, or packet loss rates between network-layer routers

  • End-to-end, between computing devices or applications

Determining what is an acceptable error or loss rate depends on the application's ability to tolerate errors or information loss. This, in turn, implies reliability and dependencies between the various layers in the network. For example, an application that transfers data in the network may rely on the transport layer to provide guaranteed transmission. If the transport layer used is the TCP, then reliability of transmission is based on TCP's ability to recover from errors in the network or on notification of transmission failures. However, if the transport protocol is the User Datagram Protocol (UDP), there is no reliability guarantee from the transport layer and reliability is passed down to the data-link and physical layers or must be provided by the application itself.

Loss is often measured at the physical, link, and network layers and reported as a percentage of available traffic in the network. Thus, we could establish cell, frame, or packet loss thresholds and time periods, as shown in Figure 3.23.

Packet Loss Rate (% of Total Network Traffic) | Maximum Total Time (Per Week)
2% or Greater | Up to 1 Minute
Less Than 2% | Remainder of Week

Figure 3.23: Example loss threshold.

The time periods for each of these loss rates exclude the others. One interesting part of such a loss measurement is that we could use the well-known ping utility as a possible measurement tool. A ping loss rate can be used as an indicator that the network is approaching a loss threshold and that a more accurate measurement (e.g., SNMP polling of router statistics or remote monitoring [RMON] variables) is needed.

Although ping can be useful in this mode, loss of ICMP packets (of which ping is two types, ICMP echo request and echo response) can be affected by how network devices (e.g., routers) handle them. For example, ping packets may be among one of the first packets to be selectively dropped by a router when it gets congested. The important point here is to use utilities such as ping with the awareness that it (like all other applications) is imperfect and may not always accurately represent the state of the system. This is why it may be better used as a threshold indicator, triggering another method of measurement when the threshold is crossed, for it would have less of a direct impact on the accuracy and loss measurements while still being quite useful.

Some applications will tolerate some loss of information. Applications that transfer video and/or voice, such as teleconferencing or telelearning, allow some loss to preserve the time continuity of the session. Some non-mission-critical telemetry applications also allow for data loss.


3.10 Environment-Specific Thresholds and Limits

General thresholds and limits give us some common estimates for low-and high-performance requirements for our network. They are useful when there is a lack of information about users, applications, and devices for the network, but often there is information about what the performance thresholds should be. With this information, we can develop thresholds and limits specific to that network.

Environment-specific thresholds and limits are an acknowledgment that each network is unique and that the requirements of users, applications, and devices are specific to the environment in which they operate. The environment takes into account concepts such as the area of work that they are doing or what their objectives are (e.g., what motivates them). Thus, an academic research environment differs drastically from a retail (sales) environment, which will differ from a manufacturing environment, and so on. The thresholds that distinguish between low and high performance will be unique to each environment.

Developing environment-specific thresholds recognizes that each environment is unique and that what may be considered high performance for one environment may be low performance for another. Recognizing the uniqueness of each environment (and thus network) that you work in is a good habit to develop, especially if you are involved with many different networks.

As with general thresholds, the reason for developing environment-specific thresholds is to determine which applications have high-performance requirements. We have spent a lot of time on this, but why is it so important? For each network project that we work on, we need to do the following:

  1. Determine whether there are any high-performance applications and devices, and if so, how important are they to the success of that environment? How important is it that they be supported? If there are no high-performance (multitier) applications, the network will be supporting a set of single-tier performance applications and devices.

  2. If there are high-performance (multitier) applications and devices and they are crucial to the success of that environment, it is likely that the network architecture and design will focus on supporting those applications and devices, as well as their users.

Thus, the ability to determine which users, applications, and devices are important to the success of the organization that the network will be supporting and the ability to determine whether those applications and devices are relatively high performance for that environment or are roughly the same as all other applications and devices there will affect the success of the resulting network architecture and design.

3.10.1 Comparing Application Requirements

Developing environment-specific thresholds and limits is based on comparing the various performance requirements of applications. Typically, one, two, or all of the performance characteristics (capacity, delay, and RMA) for the applications are plotted, and the plot is used to compare relative performance requirements and develop a threshold or limits for that characteristic.

For example, consider a plot of capacity requirements for applications in a network. These may be a subset of all the applications in that environment, such as the top five or six in order of performance or importance. Figure 3.24 shows the resulting plot. There is a cluster of applications in the capacity range of 50 Kb/s—around 1 Mb/s—then there are isolated applications at around 4 and 6.5 Mb/s. We could choose to pick the top one or two applications and place a threshold between them and the rest of the applications. Most likely, the top two would be grouped together and a threshold placed around 2 to 3 Mb/s.

Click To expand
Figure 3.24: Plot of capacity requirements with possible thresholds.

As you can see from Figure 3.24, the capacity requirements of the applications are spread across a range of values. We could choose to develop an environment-specific performance limit for this group of applications or a threshold between low and high performance, or both. Note that, for delay, an upper limit for high performance is actually the lowest delay value, not the highest value.

In Figure 3.24, we could estimate a couple of possible capacity thresholds. The most likely would be grouping applications C and F and placing a threshold around 2 to 3 Mb/s. This value is subjective and may need to be approved by the users or management. Sometimes, the threshold or limit is obvious; at other times, it may be difficult to determine. Consider, for example, the following plot of application capacities (Figure 3.25).

Click To expand
Figure 3.25: Plot of capacity requirements with no distinct groupings.

In Figure 3.25, the capacity requirements are also spread out over a range of values, but in this case there is no clear separation between low and high performance. When performance requirements are not clearly separated, you may not be able to develop a threshold.


3.11 Requirements for Predictable and Guaranteed Performance

Along with determining performance requirements, thresholds, and limits, we must also consider whether there are any requirements for predictable or guaranteed performance. You may recall from Chapter 1 that predictable service (of which performance is a part) requires some predictability and reliability, more than best effort, whereas guaranteed service has accountability as part of its specification. The performance requirements for both of these service types are much more strict than the standard best-effort service. Thus, when specifying predictable and/or guaranteed performance for a network, you will want to be certain that they really need or want it and that they are aware of the costs (e.g., financial, personnel, intellectual, possibly schedule) to implement and maintain it.

3.11.1 Requirements for Predictable Performance

Several of the examples we have discussed in this chapter may be considered predictable. Depending on how important the users and applications are to the success of that organization, their requirements may need to be predictable, requiring more support for their traffic flows. This would mean that, in the network architecture and design, their flows are handled differently from best effort. How that will be done will be covered later in this book, but for now, it is sufficient to be able to identify and specify such predictable performance requirements.

There have been several indicators of predictable performance so far in this book. We have talked about mission-critical, rate-critical, real-time, and interactive applications. They indicate predictable or guaranteed capacity, delay, and RMA, respectively. We have also talked about developing general and environment-specific thresholds and limits to separate low and high performance for multitier performance networks. Those applications that are characterized as high performance are also candidates for predictable service. In fact, the threshold between low and high performance can often be the threshold between best-effort and predictable service.

Therefore, whether or not you specify performance requirements as predictable is based on the following:

  • Determining whether the application is mission-critical, rate-critical, real-time, or interactive

  • Determining whether there are any environment-specific performance thresholds or limits

  • Applying general thresholds and limits, if necessary

  • Discussing the results with your customer(s) (e.g., users, management) to agree on which requirements should be considered predictable

3.11.2 Requirements for Guaranteed Performance

Guaranteed performance requirements are the most strict requirements for the network—not necessarily in terms of the level of performance but in terms of what is needed to support (or guarantee) that performance to the device, application, or user. As with predictable requirements, guaranteed requirements are indicated when mission-critical, rate-critical, real-time, and interactive applications are identified, as well as when high-performance (multitier) requirements are identified.

What makes a performance requirement guaranteed is the degree to which that requirement needs to be supported in the network. Support for guaranteed requirements has to have accountability built into it. This means:

  • There must be some agreement, usually between users of the application and providers of the network service, that supports the application, about the following:

    1. What the performance requirements are

    2. When and where they apply

    3. How they will be measured and verified

    4. What happens when a requirement is not met

  • This agreement may be in the form of an SLA, commonly used by service providers.

  • The requirements must be considered end-to-end, between source and destination. You can find more on this in Chapter 4.

The factors used to determine guaranteed performance requirements are the same as those for predictable performance requirements, with particular emphasis on the last factor (discussing the results with your customer). Getting agreement from your customer on which performance requirements must be guaranteed is especially important, for the impact on resources can be substantial.

As we will see, how you specify requirements here will have a serious impact on the network architecture and design to follow. Therefore, the more effort you put into this, the better your resulting architecture and design will be.


3.12 Requirements Mapping

Another part of the requirements analysis process is mapping requirements. In Chapter 2, we discussed the importance of determining the locations of important devices and applications. As part of the analysis process, we will bring that location information together into a map of where devices are (or are likely to be) and where applications apply (or are likely to apply).

Requirements are mapped to a geographic description of the environment. This may be a building or campus but can also be abstracted to metropolitan-area or wide-area views. In fact, there can be multiple views of the environment, each focusing on a particular geographic area. For example, one map may be a wide-area view, showing the cities where the devices and applications apply. Each city may then have its own map, showing the campuses and/or buildings (Figure 3.26).

Click To expand
Figure 3.26: Multiple requirements maps.

Figure 3.27 shows an example of a requirements map. On this map of a campus, the locations of devices (servers and specialized devices) and applications are placed. From this map, we can begin to correlate which parts of the campus will be using which applications and devices and can estimate where traffic flows might occur, within an application, between applications, and between devices.

Click To expand
Figure 3.27: Campus requirements map.

Note that on this map, groups of generic computing devices are also shown. Showing individual desktop or laptop devices is not practical and is not likely to provide important information. Showing groups, however, gives an indication of how many devices (and users) are in a particular location. This will be useful in the flow analysis process.

The degenerate case of a requirements map is one in which all applications apply everywhere, and there are no servers or specialized devices to show. In this case there is little, if any, information that can be determined by such a map.


3.13 Developing the Requirements Specification

The requirements specification and requirements map include the results of the analysis process. The first part of the process is determining any initial conditions for the project. This includes the type of network project, scope of the project, project goals, and political, administrative, and financial forces acting on the project. Part of the initial conditions of the project may be determining whether the network is single-tier or multitier performance. We would also do a rapid, initial evaluation of the problems in the network, if any, and estimate resources and schedule.

Thus, before we gather any requirements for the network, we should have some or all of this information documented. Consider the example of a building network from Chapter 2. The first part of the requirements specification may look like Figure 3.28.

Requirements Specification
Section 1—Initial Conditions
Project Type | Upgrade of building network
Project Scope | Single building, two floors, approximately 150 users
Project Goals | Improve performance to all users, particularly some mission-critical applications, and increase security to Internet
Other Conditions | Financial TBD
Problem Evaluation and Definition |  | Application performance has been a recurring problem, so management wants to upgrade network and has suggested upgrading interfaces to Fast Ethernet. Some users have GigE interfaces on their workstations.

Figure 3.28: Template for initial conditions.

The second part of the requirements specification includes the gathered and derived requirements for the network. In this example, some requirements were learned in the initial discussion with the customer (management and staff). These requirements are shown in Figure 3.29, using the template from Chapter 2.

Requirements Specification
Section 2—Listing of Requirements
ID/Name | Date | Type | Description | Gathered/ | Locations | Status | Priority
1 | 14Jan03 | User | User distribution is 60 engineers, 15 HR and Finance, 30 Manufacturing, 10 Management, 30 Sales/Marketing, 5 Other. | Gathered from Management | TBD | Info | TBD
2 | 14Jan03 | Network | Each area of the building must support Fast Ethernet connections to the backbone. | Gathered from Management | TBD | TBD | TBD
3 | 14Jan03 | Application | Database, Visualization, Manufacturing, and Payroll applications are considered mission-critical for this company. More information needed. | Gathered from Management | TBD | TBD | TBD
4 | 14Jan03 | Application | Payroll application (PAY1) requires 100% uptime (while in operation) between finance and outside payroll company. | Gathered from Management | TBD | TBD | TBD
5 | 14Jan03 | Network | Company must be kept secure from Internet attacks. | Gathered from Management | TBD | TBD | TBD

Figure 3.29: Requirements gathered from initial meeting with customer.

Requirements can't always be gathered from early meetings, though. To get requirements from users, we usually ask them questions about their environment. For this example, a questionnaire was developed and sent to all employees of the company. Figure 3.30 shows an example of such a questionnaire.

  1. List applications that you use

How often? (times per day)

How long each time?

Application 1 -

Application 2 -

Application 3 -

Application 4 -

Application 5 -

  2. List computers or other devices that you use that are connected to network

Network interface

Operating system

Device 1 (Desktop/Laptop) -

Device 2 -

  3. Have you experienced any problems with the network? If so, please give a brief description of each problem

Problems -

  4. What capabilities would you like to see in the network (performance, features)

Performance -

Features -

Other -

  5. Do you have any issues or problems with security? If so, please give a brief description of each problem.

Security Problems -

  6. Any other suggestions, issues, or comments?

Suggestions/

Issues/

Comments

Figure 3.30: Template for questionnaire.

Of course, not everyone will respond to the questionnaire. Experience has shown that anywhere from 10% to 40% will respond. This depends on how long the questionnaire is, how difficult it is to fill out, and how large the organization is. Also, you will get most of the responses within a few days, but some will trickle in over a longer period (e.g., a few weeks). You can update the requirements a few times based on the results of new responses.

The results of the example questionnaire are shown in Figures 3.31 and 3.32.

Requirements Specification
Section 2—Listing of Requirements
ID/Name | Date | Type | Description | Gathered/Derived | Locations | Status | Priority
6 | 20Jan03 | Application | Inventory application (INV1) for manufacturing requirements not determined at this time. | Gathered from Users (MAN) | TBD | TBD | TBD
7 | 25Jan03 | Device | Engineering users have workstations with GigE NICs. | Gathered from Users (ENG) | TBD | TBD | TBD
8 | 02Feb03 | Application | Other general applications: mail, word processing, internal and external Web access. More information needed. | Gathered from Network Staff | TBD | TBD | TBD

Figure 3.31: Additional requirements gathered from questionnaire.
Requirements Specification
Section 2—Listing of Requirements
ID/ Name | Date | Type | Description | Gathered/Derived | Locations | Status | Priority
9 | 01Feb03 | Application | Database application (DB1) requires a minimum of 150 Kb/s per session. | Gathered from Various Users | TBD | TBD | TBD
10 | 02Feb03 | Network | Company requires a minimum of T1 access to Internet. | Gathered from Network Staff | TBD | TBD | TBD
11 | 02Feb03 | Network | Current network will be completely replaced, so there are no requirements from existing network. | Gathered from Network Staff | N/A | Info | TBD
12 | 05Feb03 | Application | Visualization application (VIS1) for finance requires up to 40 Mb/s capacity and 100-ms round-trip delay. | Derived from Application | TBD | TBD | TBD

Figure 3.32: Additional requirements gathered from meetings with users and staff.

These requirements were refined and added to by meeting with each of the groups (including meetings with management and network staff) in the company.


3.14 Conclusion

The process of requirements analysis provides you with the means for analyzing your network, system, and the environment in which it is contained. You learned about gathering and managing user, application, device, and network requirements. This includes determining the initial conditions for the project and setting and managing your customer's expectations about the network. Initial conditions vary, depending on the network, system, and environment, as well as whether the network is new or an upgrade of an existing network. Armed with the initial conditions, you can gather requirements from the users, administration, and management and map application requirements to determine their dependencies.

You learned about determining which variables to measure (service metrics) and how to make measurements. Your choices of service metrics will lead to defining variables for network monitoring and management. We discussed modeling and simulation and how they and other approximation techniques can be used to describe user and application behavior.

Building on the service metrics, you learned about developing performance requirements for capacity, delay, and RMA, including developing performance thresholds and limits. These are useful in distinguishing between low and high performance for your network. You also learned about general and environment-specific thresholds and limits and how to determine them. Some general thresholds are presented for your use. We also discussed predictable and guaranteed performance requirements and their importance. Finally, we discussed mapping requirements to geographic locations in preparation for traffic flow analysis.

In Chapter 4, all of these concepts come together to develop a requirements specification for the network.


3.15 Exercises

  1. Initial conditions for your network project consist of the following categories: type of network project, scope of network project, and architecture/design goals. Develop three sets of initial conditions (each containing one element from each category) and give an example network project for each set.

  2. For each set of application performance requirements shown in Figure 3.33, classify the network as single-tier or multitier performance.

    Application Set

    Performance Requirements

    Capacity

    Reliability

    Delay

    Application Set 1:

    Application 1

    150 Kb/s

    N/A

    N/A

    Application 2

    200 Kb/s

    N/A

    N/A

    Application 3

    90 Kb/s

    N/A

    N/A

    Application 4

    120 Kb/s

    N/A

    N/A

    Application Set 2:

    Application 1

    75 Kb/s

    99.999%

    N/A

    Application 2

    150 Kb/s

    N/A

    N/A

    Application 3

    250 Kb/s

    99.999%

    N/A

    Application 4

    200 Kb/s

    N/A

    N/A

    Application Set 3:

    Application 1

    1.1 Mb/s

    99.95%

    40 ms

    Application 2

    800 Kb/s

    N/A

    N/A

    Application 3

    950 Kb/s

    N/A

    100 ms

    Application 4

    120 Kb/s

    N/A

    N/A

    Figure 3.33: Application performance requirements for Exercise 2.

  3. Your customer is a hospital that wants to upgrade its LAN. Develop a questionnaire to gather requirements from users, hospital management, and staff. What kinds of questions would you ask to better understand the environment?

  4. Consider a network project in which you cannot talk to users or staff. What resources can you use to gather user, application, device, and network requirements? Briefly outline a method for gathering and deriving requirements in the absence of user and staff involvement.

  5. You want to test the performance of Web sessions across a wireless access network, between PCs and an IP router that terminates point-to-point protocol (PPP) and PPP over Ethernet (PPPoE) sessions, as shown in Figure 3.34. Describe how you would test performance, both on a testbed and on the existing network. List any equipment, software, and networking devices you would use.

    Click To expand
    Figure 3.34: Wireless connections to corporate network using PPP and PPPoE.

  6. Show how the following changes to the following requirement would be tracked/managed. Use either the paragraph or the tabular form to record changes.

    Requirement:

    12Oct2002. Network must be capable of supporting up to 2000 Fast Ethernet interfaces, aggregated to a 1 Gb/s or greater capacity backbone spanning all 12 buildings across the campus.

    1. Change "Fast Ethernet" to "Fast Ethernet or Gigabit Ethernet," dated 5Jan2003.

    2. Delete "12 buildings across the campus," dated 7Jan2003.

    3. Change "2000" to "3500," dated 10Feb2003.

    4. Add "10 buildings listed in Appendix A," dated 20Jan2003.

    5. Change "Fast Ethernet" to "Fast Ethernet or Gigabit Ethernet" to "10, 100, or 1000 Mb/s," dated 5Mar2003.

    6. Change "aggregated" to "aggregated within each building," dated 21Apr2003.

  7. Service metrics are used to monitor, measure, and verify services in the network and to determine whether performance requirements are being met. Therefore, service metrics must be meaningful to the network operators, managers, users, and staff. For each performance requirement given, describe a service metric that could be used to measure and verify the requirement.

    1. Reliability of a T1 link between an enterprise network and its ISP, with IP routers on each end of the T1 line

    2. Round-trip delay between devices on network A and servers on server LAN B

    3. Average traffic rate in and out of a compute server, measured across all four of its LAN interfaces over 15-minute intervals

  8. Given an MTBCF requirement of 8000 hours and an MTTR requirement of 4 hours, calculate an availability requirement.

  9. Describe two ways to make an uptime requirement of 99.999% more precise.

  10. You are developing a network for the FAA for a telemetry-processing application that consists of two components: an automated guidance-control system that will analyze telemetry data from airplanes and a motion-visualization system used by controllers at their workstations (Figure 3.35). In your analysis of this application, you have determined that the application requires a maximum one-way delay of 20 ms between an airplane and the guidance-control system. In addition, controllers interact with airplanes via the motion-visualization system with delays on the order of HRT. Develop upper and lower delay bounds for this application, and show them on a graph.

    Click To expand
    Figure 3.35: Diagram of system for Exercise 10.


Chapter 4: Flow Analysis

The results of requirements analysis—the requirements specification and requirements map—list and describe requirements that have been gathered and derived for a network. Many of these will be performance requirements (capacity, delay, and reliability, maintainability, and availability [RMA]) for users, their applications, and devices. Such performance requirements, along with the locations of users, applications, and devices from the requirements map, form the basis for estimating where traffic will flow through the network. Flow analysis is the process of characterizing traffic flows for a network, where they are likely to occur and what levels of performance they will require.

The intent of flow analysis is not to show every possible flow in a network but rather to show those flows that will have the greatest impact on the network architecture and design. This is often a small fraction of the total set of flows for a network.

4.1 Objectives

In this chapter, you will learn how to identify and characterize traffic flows. We will discuss individual, composite, and critical flows and how to determine when each applies. You will learn mechanisms to help identify and characterize flows, including data sources and sinks and flow models. Finally, you will learn about flow specifications, where performance requirements are combined for a flow or group of flows. Flow specifications are used as input to the network architecture and design processes, covered later in this book.


4.2 Preparation

To be able to understand and apply the concepts in this chapter, you should be familiar with client-server, peer-to-peer, distributed computing, and other models for how applications and devices interact with each other. Some recommended sources of information include the following:

  • Successful SAP R/3 Implementation: Practical Management of ERP Projects, by Norbert Welti, Addison-Wesley Publishing, February 1999

  • A Methodology for Client/Server and Web Application Development, by Roger Fournier, Prentice Hall, September 1998

  • David Linthicum's Guide to Client/Server and Intranet Development, by David Linthicum, John Wiley & Sons, May 1997

  • Peer-to-Peer: Building Secure, Scalable, and Manageable Networks, by John Hebeler and Dana Moore, McGraw-Hill Osbourne Media, November 2001

  • An Introduction to Distributed and Parallel Computing, by Joel Crichlow, Prentice Hall, January 1988


4.3 Background

Now that we have the user, application, device, and network requirements developed, listed, and mapped in the requirements specification, we will further analyze these requirements based on their end-to-end characteristics. We will use the concept of a flow, which, for an end-to-end connection, has constant addressing and service requirements, to combine performance requirements in a useful way. These characteristics will be analyzed and combined, per flow, into a flow specification, or flowspec. This will be used for capacity and service planning.

This chapter introduces flows and flow concepts, data sources and sinks, and flow models, which will help us identify, size, and describe flows. We will also develop cumulative performance requirements for each flow.


4.4 Flows

Flows (also known as traffic flows or data flows) are sets of network traffic (application, protocol, and control information) that have common attributes, such as source/destination address, type of information, directionality, or other end-to-end information. Figure 4.1 illustrates this concept.

Click To expand
Figure 4.1: Flow attributes apply end-to-end and throughout network.

Information within a flow is transmitted during a single session of an application. Flows are end-to-end, between source and destination applications/devices/users. Since they can be identified by their end-to-end information, they can be directly linked to an application, device, or network or can be associated with an end user. We can also examine flows on a link-by-link or network-by-network basis. This is useful when we want to combine flow requirements at the network or network-element levels. Common flow characteristics are shown in Figure 4.2.

Flow Characteristics
Performance Requirements | Capacity (e.g., Bandwidth)
 | Delay (e.g., Latency)
 | Reliability (e.g., Availability)
 | Quality of Service Levels
Importance/Priority Levels | Business/Enterprise/Provider
 | Political
Other | Directionality
 | Common Sets of Users, Applications, Devices
 | Scheduling (e.g., Time-of-Day)
 | Protocols Used
 | Addresses/Ports
 | Security/Privacy Requirements

Figure 4.2: Common flow characteristics.

Flow analysis is an integral part of the overall analysis process. Flows are where performance requirements, services, and service metrics are combined with location information to show where performance and service are needed in the network. Flow analysis provides an end-to-end perspective on requirements and shows where requirements combine and interact. It also provides some insight into the degrees of hierarchy and interconnectivity needed in the architecture and design. In addition, as we will see in the design process, this analysis also provides information that can be useful in choosing interconnection strategies, such as switching, routing, or hybrid mechanisms.

Most flows are bidirectional and can be represented as either a double-sided arrow with one or two sets of performance requirements or as two separate flows, each with its own set of requirements. A single-sided arrow with one set of performance requirements represents a unidirectional flow. Figure 4.3 shows these cases.

Click To expand
Figure 4.3: Flows are represented as unidirectional or bidirectional arrows with performance requirements.

Flows provide a different perspective on traffic movement in networks: They have logical and physical components, and they allow traffic to be coupled with users, applications, or devices. Flows are becoming increasingly important in the analysis, architecture, and design processes.

We will examine two types of flows: individual and composite. We will see that the aggregation of requirements and flows in the network as a result of hierarchy will lead to composite flows and that this can happen in the access network and in the backbone.

4.4.1 Individual and Composite Flows

An individual flow is the flow for a single session of an application. An individual flow is the basic unit of traffic flows in this book; either they are considered individually or they are combined into a composite flow. When an individual flow has guaranteed requirements, those requirements are usually left with the individual flow and are not consolidated with other requirements or flows into a composite flow (Figure 4.4).

Click To expand
Figure 4.4: Individual flow for a single application with guaranteed requirements.

This is done so that the flow's guaranteed requirements can be treated separately from the rest of the flows. Individual flows are derived directly from the requirements specification or are estimated from our best knowledge about the application, users, and devices, as well as their locations.

A composite flow is a combination of requirements from multiple applications or of individual flows that share a common link, path, or network. Most flows in a network are composites (Figure 4.5).

Click To expand
Figure 4.5: Example composite flows.

More examples of flows are presented in Figure 4.6. The first example is an individual flow, consisting of a one-way delay requirement for a single session of an application (note that this flow is unidirectional). The second example is also of an individual flow, but in this case the capacity requirements are given in each direction. Since they are different, they are listed independently. The convention of upstream and downstream is used here to provide directionality based on the source and destination of the flow, where upstream indicates the direction toward the source and downstream is the direction to the destination. Upstream is often toward the core of the network, and downstream is often toward the edge of the network, particularly in service-provider networks. Another way to show a bidirectional flow is with two arrows, one upstream and the other downstream, each with its own performance requirement.

Figure 4.6: Flow examples.

The third example is a composite flow, listing requirements from three applications at the same source. The last example uses a performance profile to describe the flow's performance requirements. A profile is often used when many flows have the same requirement. In this case, developing a profile makes it easier to apply the same requirements to multiple flows. Then a pointer to the profile is sufficient to describe the requirements instead of having them written out each time. This is especially useful when the requirements are long or when they are consistent across many flows. The flow in this example could be either an individual or a composite flow, depending on the contents of the profile.

Performance requirements for individual flows and composite flows are determined through development of a flow specification for the network, which is discussed at the end of this chapter.

4.4.2 Critical Flows

Some flows can be considered more important than others; that is, they are higher in performance or have strict requirements (e.g., mission-critical, rate-critical, real-time, interactive, high performance), whereas some flows may serve more important users, their applications, and devices. Such flows are called critical flows. In this chapter, we will examine how to determine when flows are critical. When prioritizing which flows get attention in the network architecture and design, critical flows usually come first. This is usually the case, but individual flows with guaranteed requirements might also be considered first in the architecture and design. Prioritizing flows will be discussed at the end of this chapter.

Flows are described in this fashion to make it easier to understand and combine requirements. Composite flows combine the requirements of individual flows, whereas individual flows can show guaranteed requirements that must be considered throughout the end-to-end path of the flow. All of these flows are important in the architecture and design of the network. The descriptions of the types of flows that we develop in the flow specification will help us define the architecture and choose the technologies and services that best fit the customer's needs.

Throughout this chapter, we will analyze flow requirements to determine where they apply and when they contribute to composite flows and, if so, how to combine their performance requirements accordingly. Some networks will have flows that indicate single-tier performance, others will have flows that indicate multitier performance, and still others will have flows that have predictable (stochastic) and/or guaranteed performance. Often, the few flows that require high, predictable, and/or guaranteed performance will be the ones that drive the architecture and design from a service (capacity, delay, and RMA) perspective, and all flows will drive the architecture and design from a capacity perspective. The architecture and design processes accommodate both of these perspectives.


4.5 Identifying and Developing Flows

Flows can usually be identified and developed from information in the requirements specification: user, application, device, and network requirements; user and application behavior (usage patterns, models); user, application, and device location information; and performance requirements. The more thorough this information is, the better the resulting flows will be.

At this point in the analysis process, we have sets of requirements and mappings of application and/or device locations. We have not made any choices of networking technologies, network devices, or vendors. During the flow analysis process, we must not constrain flows to existing networks, topologies, or technologies. We want to be free in determining the compositions and locations of flows for our network so that the flows drive our architectural and design choices. Thus, flows are determined based on the requirements and locations of the applications and devices that generate (source) or terminate (sink) each traffic flow.

The process for identifying and developing flows consists of identifying one or more applications and/or devices that you believe will generate and/or terminate traffic flows. Once you have chosen which applications and devices to focus on, you will use their requirements from the requirements specification and their locations from the requirements map. Based on how and where each application and device is used, you may be able to determine which devices generate flows and which devices terminate flows (flow sources and sinks, respectively). Some common flow models are provided in Section 4.7 to help you with this process. Once you have identified each flow and determined its composition and location, you will combine the performance requirements of flows into a flow specification. This process is shown in Figure 4.7.

Click To expand
Figure 4.7: Process for identifying and developing flows.

From an application perspective, some common approaches to identifying flows include:

  • Focusing on a particular application, application group, device or function (e.g., video conferencing, storage)

  • Developing a "profile" of common or selected applications that can be applied across a user population

  • Choosing the top N (e.g., 3, 5, 10, etc.) applications to be applied across the entire network

You may choose to consider doing some or all approaches for your network. Each approach is outlined in the following sections.

4.5.1 Focusing on a Particular Application

When focusing on an application, application group, device, or function, you are considering one or more applications that will likely drive the architecture and design— those that are high performance, mission-critical, rate-critical, real-time, interactive, predictable, and/or guaranteed. By focusing on one or a few applications, you will be able to spend more time determining their flows, as opposed to spreading your time across many applications. Choose what you are focusing on and select that information from the requirements specification.

4.5.2 Developing a Profile

Sometimes a set of common applications applies to a group of users or to the entire set of users. When this is the case, a profile or template can be developed for those applications, and each flow that fits the profile is identified with that profile's tag. Thus, instead of trying to replicate flow information for similar flows, you can use the profile, saving time and effort.

There are also times when flows have the same performance requirements, regardless of whether they share the same set of applications. When flows have the same performance requirements, a profile can be used to simplify their information as well.

Figure 4.13 shows a profile applied across the user population for Application 1 in Example 4.1. Instead of showing identical performance requirements at each flow, a common profile is shown for flows with the same performance requirements. This helps reduce duplication of information on the map, also reducing clutter.

Example 4.1: Data Migration
Start example

From the requirements specification, for a single session of each application:

Application 1—staging data from user devices

Capacity, 100 Kb/s; delay, unknown; reliability, 100%

Application 1—migrating data between servers

Capacity, 500 Kb/s; delay, unknown; reliability, 100%

Application 2—migration to remote (tertiary) storage

Capacity, 10Mb/s; delay, N/A; reliability, 100%

You can use the location information to map out where the users, applications, and devices are and develop a map if you do not already have one. Figure 4.8 is an example of such a map.

Click To expand
Figure 4.8: Map of device locations for a network.

Using the information on user and application behavior, you can determine or estimate where flows will occur. This can be between networks, device groups (better), or individual devices (best). Figure 4.9 shows where flows will occur between devices for Application 1.

Click To expand
Figure 4.9: Flows estimated between devices for Application 1.

Once flows are mapped, you can apply performance information to each flow. Figure 4.10 shows this for the central campus portion of the storage application environment. Although in Figure 4.9 flows are shown between devices, Figure 4.10 simplifies this view by showing flows between buildings. Either method can be used, depending on the size of the environment and number of flows that you need to show. Usually the first method (Figure 4.9) is used to estimate where flows will be, and then the second method (Figure 4.10) is used to simplify the flow diagram.

Click To expand
Figure 4.10: Performance information added to central campus flows for Application 1.

In Figure 4.10, flows F1, F2, and F3 represent the single-session performance requirement for each building for Application 1. At some point in this process, the performance requirement will need to be modified to represent the estimated performance required by all users in each building (40, 67, and 45 users in the buildings at the central campus). F4 represents the performance requirement for the server-server flow between the central and north campuses.

Note that in Figure 4.10 flows F1 and F2 are between Buildings A/B and C, and flow F3 is between devices. Given that the 45 user devices and the 4 servers are in the same building, we have to show the flows between devices. If we were showing flows within Building C, it would look like Figure 4.11.

Click To expand
Figure 4.11: Central campus flows for Application 1 expanded with Building C.

Figure 4.11 also introduces a flow aggregation point, which allows us to show multiple flows being consolidated at a location. This will be useful in the design process, when we are looking at technologies and interconnection strategies for such locations in the network. For example, Figure 4.12 shows what flows will look like between buildings with and without a flow aggregation point.

Click To expand
Figure 4.12: Consolidating flows using a flow aggregation point.

End example

In Figure 4.13, P1 is the profile tag assigned to flows that have performance requirements (capacity = 100 Kb/s, reliability = 100%). There are six flows (tagged P1) in this diagram with those performance requirements. Other flows in Figure 4.13 have different performance requirements. For example, flow F4 (also shown in Figures 4.10 and 4.11) has performance requirements (capacity = 500 Kb/s, reliability = 100%). Flow F5 combines the performance requirements of 51 users (which, for Application 1, would be P1) with those of the 2 servers in that building. Flow F6 combines the performance requirements of 14 users (again, this would be P1) with that of the digital-video device. Flow F7, like flow F5, combines the performance requirements of users (88 in this building) with those of the 2 compute servers.

Note that Figure 4.13 shows flows as arrows between buildings and between devices within a building (except for flow F4, which in this example is easier to show as a flow between devices than as a flow between buildings). We could also choose to show the flows just between devices, as in Figure 4.9. If you compare these two figures, you will see that showing arrows between buildings simplifies the diagram. However, you may need to complement such a diagram with diagrams of flows within buildings, such as that shown in Figure 4.11.

Click To expand
Figure 4.13: A performance profile (P1) applied to multiple flows with the same performance characteristics.

4.5.3 Choosing the Top N Applications

Finally, choosing the top N applications for your network is a combination of the first two approaches. It is similar to the first approach, but instead of 1 particular application (or maybe 2 applications), you use 3, 5, 10, and so on. It is also similar to the second approach in that the result can also be an application profile. These applications are the "top N" in terms of helping with the success of that organization, which may be inferred by their degrees of usage, number of users, number of devices/servers, or performance requirements. For example, the top five applications may be:

  1. Web browsing

  2. Email

  3. File transfer

  4. Word processing

  5. Database transactions

This approach reduces the set of possible applications to a number that can be analyzed. However, when you eliminate applications from this set, you need to ask the question, "If I meet the requirements of these top N applications, will the requirements for those applications I eliminated be met?" The intent of this approach is to determine which applications represent the most important requirements for that network. These "top N" applications are likely to be the performance drivers for the network. As such, if you meet the needs of these applications, you are likely to meet the needs of all applications for that network. This will be described in more detail during the development of the flow specification.

The list of "top N" applications should be as precise as you can make it. For example, Application 5 (database transactions) may actually be timecard data entry into an enterprise resource planning (ERP) database. This would be a more precise description, resulting in more precise flow composition and location information. When possible, include usage scenarios for each application.

You may also use different approaches for different parts of the network. For example, it is common to have the top N applications that apply everywhere; profiles for selected locations; and focus on an application, device, or group in other locations, as in Figure 4.14.

Click To expand
Figure 4.14: A project may incorporate multiple approaches in choosing applications.


4.6 Data Sources and Sinks

Data sources and sinks are tools to provide directionality to flows. A data source generates a traffic flow, and a data sink terminates a traffic flow. To help show data sources and sinks in a diagram, the convention shown in Figure 4.15 is used. Data sources are represented as a circle with a dot in the center, and a data sink is represented as a circle with a cross (i.e., star or asterisk) in the center. These are 2D representations of a plane with an arrow coming out of it, as in traffic flowing out of a source, or a plane with an arrow going into it, as in traffic flowing into a sink. By using these symbols, we can show data sources and sinks on a 2D map without the need for arrows.

Click To expand
Figure 4.15: Convention for data sources and sinks.

Almost all devices on a network will produce and accept data, acting as both data sources and data sinks, although some device will typically act as either a source or a sink. In addition, a device may be primarily a data source or sink for a particular application.

Some examples of data sources are devices that do a lot of computing or processing and generate large amounts of information, such as computing servers, mainframes, parallel systems, or computing clusters. Other (specialized) devices, such as cameras, video production equipment, application servers, and medical instruments, do not necessarily do a lot of computing (in the traditional sense) but can still generate a lot of data, video, and audio that will be transmitted on the network (Figure 4.16).

Click To expand
Figure 4.16: Example data sources.

A good example of a data sink is a data-storage or archival device. This may be a single device, acting as a front end for groups of disk or tape devices. Devices that manipulate or display large quantities of information, such as video-editing or display devices, also act as data sinks (Figure 4.17).

Click To expand
Figure 4.17: Example data sinks.
Example 4.2: Data Sources and Sinks for Data Migration Applications.
Start example

As an example, let's consider the data-migration applications. Recall that Figure 4.8 shows device location information for these applications. Shown on this map are storage and compute servers, a video source, and groups of desktop devices for each building. Note that a total number of desktop devices is given, simplifying the map and flows. If more detail is needed, this group could be separated into multiple groups, based on their requirements, or single devices can be separated. If necessary, a new map could be generated for just that building, with substantially more detail.

This service has two applications. Application 1 is the frequent migration of data on users' desktops, servers, and other devices to storage servers at each campus. As part of this application, data are migrated from the server at the central campus to the server at the north campus.

The server at the south campus is also the archival (or long-term) server for these campuses. Application 2 is the migration of data that have been collected over a specific period (e.g., 1 day) from the server at the central campus to the archival server at the south campus.

When we add the data sources and sinks for Application 1 to Figure 4.13, we get Figure 4.18, in which all devices are labeled as a data source, a data sink, or both. All of the user devices at each campus are data sources. The servers at the central campus act as a data sink for flows from user devices at that campus and as a data source when data migrate to the server at the north campus (flow F4). The server at the south campus is a data sink for user flows at that campus, and the servers at the north campus are data sinks for all devices at that campus, including servers and digital video, as well as for flow F4 from the central campus.

Click To expand
Figure 4.18: Data sources, sinks, and flows added to first part of Application 1.

With the sources and sinks on the map, along with arrows between them to indicate potential traffic flows, we are beginning to have an idea of where flows are occurring in this network for this application.

We do the same thing to Application 2, with the result shown in Figure 4.19. For this part of the application, the desktop devices and video source are not involved, so they are not shown as either sources or sinks of data. The server at the central campus that was a data sink for Application 1 now becomes a data source for Application 2, sending data to the archival server (shown as a data sink). The flows for this part of the application are much simpler, merely a single flow between the storage server and the archival device. This is shown in two ways: as a flow between buildings (option 1, the standard convention used so far in this example) and as a flow between devices at separate buildings (option 2). Although option 2 is not common practice, it is used here because there are only two devices (and one flow) for this application.

Click To expand
Figure 4.19: Data sources, sinks, and flows added to Application 2 (two options shown).

These applications are shown as separate events to clarify the flows and the roles of the storage servers. We could, however, put both parts of the application together on the same map. We would want to ensure that the resultant map is still clear about when devices are data sources and sinks.

One way to simplify this map is to focus on only flows between storage servers, data sources, and sinks. Figure 4.20 shows this case, with both applications on the same map.

Click To expand
Figure 4.20: Data-migration application with server-server flows isolated.

End example

You may have noticed in the previous example that flows occur at different times of the day and can vary in schedule (when they occur), frequency (how often they occur), and duration (how long they last). The occurrence of traffic flows can be cyclic (e.g., every Monday morning before 10 AM, at the end of each month, and during the end-of-the-year closeout). Understanding when flows occur and how they affect your customer's business or operation is critical. For example, if 90% of the revenue for a business is generated the last 4 weeks before Christmas, you may need to focus flow development on what is happening to applications during that time.

This leads to the concept of developing worst-case and typical-usage scenarios. This is similar to developing for single-tier or multitier performance, as discussed in Chapter 3. Worst-case scenarios are like those described earlier for a business whose revenue is highly seasonal. This is similar to developing for the highest-performance applications and devices in that your focus is on times when the network requires its greatest performance to support the work being done. Architecting/designing a network for the worst-case scenario can be expensive and will result in overengineering the network for most of its life cycle. Therefore, the customer must be fully aware and supportive of the reasons for building toward a worst-case scenario.

Typical-usage scenarios describe an average (typical) workload for the network. This is similar to developing for single-tier performance in that your focus is on times when average, everyday work is being done. Recall from Chapter 3 that single-tier performance focuses on those applications and devices that are in general use and that make up a background level of traffic on the network. This is the average everyday work that forms a typical-usage scenario. Often both worst-case and typical-usage scenarios are developed for a network.

Using data sources and sinks to help map flows for an application provides a great start to generating the flows for your network. Flow models, described next, is another great tool that you can use to help describe flows.


4.7 Flow Models

Another method to help describe flows in the network is to compare them with general, well-known flow models. Flow models are groups of flows that exhibit specific, consistent behavior characteristics. The flows within a flow model apply to a single application. Directionality, hierarchy, and interconnectivity are the primary characteristics of flow models. Directionality describes the preference (of lack thereof) of a flow to have more requirements in one direction than another. Hierarchy and interconnectivity are based on the definitions from Chapter 1.

Although network architectures and designs typically treat traffic flows as having equal requirements in each direction, we are finding that many flows (especially from newer applications) have substantially different requirements in each direction. Most flows are asymmetric, and some of the newer access and transmission technologies (such as digital subscriber loop [xDSL] or ATM) can be optimized for such flows.

Flow models help describe the degrees of hierarchy and interconnectivity of flows for applications. They show where flows combine, where they can be grouped, and where flows occur between peers, which are devices at the same level in the hierarchy. They also can help us identify which flows are critical flows, which, as you may recall, are considered more important than others because they are higher in performance; have strict requirements; or serve more important users, applications, and devices.

Flow models can also be useful to help quickly identify and categorize flows in an environment so that we may easily recognize its flow characteristics. In this way, they are like application groups, discussed in Chapter 2.

We will examine the following flow models:

  • Peer-to-peer

  • Client-server

  • Hierarchical client-server

  • Distributed computing

For each model, we will consider the directionality and hierarchy of its flows. In addition, when possible, we will identify which flows in each model are critical, or important, flows.

These flow models are a subset of many possible models that you could use to characterize the flows for your network. We could include, for example, real-time (or near-real-time or interactive) flows as a model, as well as streaming media. You are encouraged to develop an exhaustive list of flow models for your network projects.

4.7.1 Peer-to-Peer

Our first flow model, peer-to-peer, is one in which the users and applications are fairly consistent throughout the network in their flow behaviors. They are, in effect, peers; that is, they act at the same level in the hierarchy. Since they (users and/or applications) are fairly consistent, their flows are also fairly consistent. Thus, we can consider the flows in a peer-to-peer flow model to be equivalent (Figure 4.21). This has two important implications:

Figure 4.21: Peer-to-peer flow model.

  • We cannot distinguish between flows in this model. Therefore, either all of the flows or none of the flows are critical.

  • The flows are equivalent, so they can be described by a single specification (i.e., profile).

There are several examples of peer-to-peer flow behavior. The first is the early Internet, a portion of which is shown in Figure 4.22. In the early Internet, applications such as FTP and telnet were predominant, and each device on the network was a potential source and destination of the flows for these applications.

Click To expand
Figure 4.22: Example of peer-to-peer flows in the early Internet.

Another example is of file-sharing applications on the Internet. Basically, anywhere devices communicate directly with each other is considered peer-to-peer.

The peer-to-peer flow model is our default model when we do not have any other information about the flows in our network. In a sense, it is part of the degenerate case for our requirements map (since no flow-specific requirements can be determined). This flow model can also be used to describe flows when all users in a group need equal access to each other for an application. In addition to the file-sharing and remote access applications already described, this could also be a multimedia, tele*services application (e.g., teleseminars, telelearning, teleconferencing), in which any of the participants may source/sink data to/from any other participant. Although each of the tele*services listed can be considered a one-to-many application, there are components of each that can be applied as a set of one-to-one conversations. For example, while telelearning consists of a number of users (students) receiving and transmitting from and to a teacher, another component to this application is the ability to have side conversations between students. This part of the application is peer-to-peer (Figure 4.23).

Click To expand
Figure 4.23: Peer-to-peer flows in a telelearning environment.

This flow model is useful in that it indicates that a performance profile may be used for those flows and that there are no (or several) critical flows for that application.

4.7.2 Client-Server

The client-server flow model is currently the most generally applicable model. This model has both directionality and hierarchy. Flows in this model are bidirectional, between clients and the server, in the form of requests and responses. This flow model is client-server because the flows are asymmetric and hierarchically focused toward the client. Thus, requests tend to be small compared with responses. Depending on the type of application, the flows may be considered almost unidirectional, from the server to the clients. Figure 4.24 illustrates the client-server flow model.

Click To expand
Figure 4.24: Client-server flow model.

Since the flows in the client-server model are asymmetric, with the predominant or important flows in the direction from the server to the clients, the server can be considered a data source and the clients data sinks. The server would be shown as a data source on the requirements map, with flows generating from it to its clients on other areas of the map. Since the predominant or important flows are from the server to the clients, these are the critical flows for this model. When there is a requirement to transmit information to multiple clients concurrently, multicasting at some layer in the network will need to be considered to optimize flows for this model.

This model is the traditional view of client-server operations, exemplified by ERP applications like SAP, as well as e-commerce applications. Applications such as these are highly dependent on network performance when they are configured to work across significant distances, such as when a company is dispersed across multiple locations, spanning cities, states, or countries. If the network does not properly support client-server applications, the customer will have to resort to distributing the clientserver architecture (e.g., distributed ERP), which can be expensive.

An example of a client-server flow model is in video editing. A video server can store video to be edited, and clients make requests to that server for video to edit. The server passes video to the clients, which may be sent back to the server upon completion or may be sent elsewhere for more processing (Figure 4.25).

Click To expand
Figure 4.25: Example of client-server flows.

Another view of client-server flows is with Web applications. Although the early Internet started with peer-to-peer flows from applications such as FTP and telnet, this usage evolved to become more client-server like with the use of FTP servers, followed by applications such as gopher and Archie. Now, with the widespread use of Web applications, many flows in the Internet are between Web servers and their clients. As TCP/IP assumes more network operating system (NOS) roles, print and file services across enterprise networks and the Internet will become more client-server-oriented. For example, in the early days, a person who wanted to access information from an organization would have used the application FTP to a known site to download information. This changed into accessing an FTP or gopher server, then to accessing a Web server. Today, a person may access large quantities of information from an organization without ever entering that organization's network by gaining access through external Web servers.

However, a better flow model for Web traffic has multiple levels of tiers, with traffic flows within some of the tiers. This is the hierarchical client-server model, described in the following section.

4.7.3 Hierarchical Client-Server

As the flows within a client-server flow model become more hierarchical, in terms of adding layers, or tiers, to the flows, their behavior can be represented as a hierarchical client-server flow model. A hierarchical client-server flow model has the characteristics of a client-server flow model but also has multiple layers, or tiers, between servers. In this model there may also be flows from a server to a support server or management device, as shown in Figure 4.26. These flows (server-to-server and server-to-manager) may be considered critical, in addition to the server-to-client flows. With the additional layer(s) of hierarchy in this model, the servers can now be either data sources or data sinks (or both). More information may be needed about the application(s) to determine the status of these servers. This model is important because it recognizes server-to-server and server-to-manager flows.

Click To expand
Figure 4.26: Hierarchical client-server flow model.

A hierarchical client-server flow model is indicated when multiple applications work together and share information to accomplish a task or when multiple client-server applications (or multiple sessions of the same client-server application) are managed by a higher-level application. An operations support system managing several back-office applications may often be modeled in this fashion.

Critical flows for this model are dependent on application behavior. If the applications are inherently client-server and the servers are there merely to support multiple sessions, then the client-server flows may be the only critical flows. However, when the servers communicate with each other (e.g., to update a common database or share data between applications), then the server-to-server flows may be critical, possibly in addition to the client-server flows. And when there is communication to a manager (e.g., to synchronize processing or information), the server-to-manager flows may also be critical.

We have shown that the Internet has evolved from an early peer-to-peer flow model to a client-server flow model with the acceptance of Web applications. As client-server traffic has grown, however, Web servers have been replicated and distributed across the Internet, resulting in an increase in server-to-server flows. This is being done to increase the effectiveness of Web access, in part by spreading access across multiple devices and in part by locating devices closer to the access portion of the Internet, thus bypassing part or all of the core. As a result, the Internet is evolving into a more hierarchical client-server flow model.

Such hierarchical Web services are shown in Figure 4.27. In this figure, content-distribution networks (CDNs) and mirrors (introduced in Chapter 1) are used to migrate Web content between servers and provide local access to content for users.

Click To expand
Figure 4.27: Web services modeled using hierarchical client-server flow model.

In Figure 4.27 the servers can provide the same function or different functions. For example, Web-based three-tier application servers can run application and Web services on the same device while running database services on another device. In this case the flows between servers (application/Web and database) are critical for operation.

This type of flow model can also be seen with the visualization application group described in Chapter 2. An example of this is in the visualization of scientific simulations. Consider the simulation of a multipart problem. These can be found in climate modeling, fluid flow analysis, structural analysis, and others. In climate modeling there may be a simulation consisting of multiple parts—atmosphere, earth, and ocean, as shown in Figure 4.28.

Click To expand
Figure 4.28: Components of a climate-modeling problem.

Each part of the simulation in Figure 4.28 may be developed on a separate computing device, probably at different locations (based on where the various scientists are located). Since each component affects the others, at the boundaries between atmosphere, earth, and ocean, data must be passed between the computing/visualization servers for each part. The flows would look like those in Figure 4.29.

Click To expand
Figure 4.29: Hierarchical client-server model for scientific visualization.

In Figure 4.29, if the parts of the simulation are being solved at different locations, then the server-to-server flows may cross long (WAN) distances, affecting both LANs and WANs.

4.7.4 Distributed Computing

The distributed-computing flow model, shown in Figure 4.30, is the most specialized of the flow models. A distributed-computing flow model can have the inverse of the characteristics of the client-server flow model or can be a hybrid of peer-to-peer and client-server flow models. In this model, flows may be primarily between a task manager and its computing devices (like a client-server model) or between the computing devices (like a peer-to-peer model). The type of model depends on how the distributed computing is done.

Click To expand
Figure 4.30: Distributed-computing flow model.

The important characteristics of this model are that the flows can be client-server but are reversed in direction and that the computing devices may have strict performance requirements.

We can make distinctions in the distributed-computing flow model based on the relationship between the task manager and the computing devices and what the task is. This relationship can result in the computing devices being closely coupled, where there are frequent transfers of information between devices, or loosely coupled, where there may be little to no transfer of information between computing devices. Tasks may range from having a coarse granularity, where each task is dedicated to a single computing device, to having a fine granularity, where a task is subdivided between several devices and the computing is done concurrently.

When the task has a coarse granularity and the computing device relationship is loosely coupled, the distributed-computing flow model takes the form of a computing cluster or computing resource management system, where tasks are allocated to each computing device based on resource availability. Thus, each computing device communicates with the cluster server or resource manager. Figure 4.31 shows the flows for an example of a computing cluster.

Click To expand
Figure 4.31: Flows for a computing cluster.

The flows in this type of distributed-computing flow model are similar to those in the client-server flow model, in which communications are primarily between each client and the server. A difference here is that the direction of the flows is not necessarily from the computing server to its clients. In fact, the size of the task initialization file (which is, in a sense, a request) sent from the server to each computing device may be much smaller than the size of the results of the computation, which is sent from the computing device to the server. In this model the flow directionality is asymmetric, but in the opposite direction from the client-server flow model. Also, each of the flows between the computing devices and their server is independent of the other flows. There is no synchronization between individual flows. The critical flows for this model are from the computing devices to their server. Since the flows for this model are asymmetric, toward the server, the server acts as a data sink and the computing devices act as data sources.

When the task has a fine granularity and the computing node relationship is closely coupled, the distributed-computing flow model behaves like a simplified parallel processing system, whereby each task is subdivided based on degree of parallelism in the application and topology of the problem, between several computing devices. These devices work concurrently on the problem, exchanging information with neighbor devices and expecting (and waiting for) updated information. The task manager set up the computing devices and starts the task with an initialization file, as in Figure 4.32.

Click To expand
Figure 4.32: Flows for parallel computing.

Flows in this type of distributed-computing flow model can have the most stringent performance requirements of any of the models. Since computing devices may block (halt their computations) while waiting for information from neighbor devices, the timing of information transfer between computing devices becomes critical. This has a direct impact on the delay and delay variation requirements for the network connecting the devices. Although each individual flow has directionality, collectively there is little or no overall directionality. Individual flows in this model can be grouped to indicate which neighbor devices a computing device will communicate with for a given problem or topology. For example, a problem may be configured so that a computing device will communicate with one, two, four, or six of its closest neighbors.

For this model, critical flows are between computing devices. When a device will transfer the same information to several neighbors simultaneously, multicasting should be considered to optimize flow performance. There are not clear data sources or sinks for this model. The climate-modeling problem shown in Figure 4.28 could also be considered with a distributed-computing flow model, depending on the task granularity and degree of coupling within the system.

Flow requirements will vary between the computing cluster and parallel system models, depending on the degrees of coupling and granularity in the task. Depending on the application and amount of analysis you want to put into this model, you can use the computing cluster and parallel system models as they are or you can modify the task granularity and degree of coupling to suit your needs.


4.8 Flow Prioritization

In developing and describing flows for your network, you may find it useful to prioritize flows. Flow prioritization is ranking flows based on their importance, which can be described in various ways, depending on your environment. Flows can be prioritized according to importance, based on the characteristics shown in Figure 4.2. Some common prioritizations include:

  • Business objectives and the impact of a flow on the customer's business

  • Political objectives

  • One or more of the performance requirements of the flow (a subset of capacity, delay, RMA, quality of service)

  • Security requirements for each flow

  • The numbers of users, applications, and/or devices that a flow serves

The purpose for prioritizing flows is to determine which flows get most resources or which flows get resources first. Typically the primary resource is funding. This is an entirely new way of looking at how to allocate funding for parts of the network. By doing it based on flows, which are directly representative of the users and their applications and devices, the resulting network architecture and design are better representations of user, application, and device requirements.

You may use more than one parameter for prioritization, creating multiple levels of priority. It is common to start by prioritizing based on the number of users that a flows supports, then adding another parameter, such as a performance requirement (e.g., capacity). Some example prioritizations are presented in Figures 4.33 and 4.34.

Flow ID | Performance Requirements |  |  | Number of Users
 | Reliability | Capacity | Delay
F1 | N/A | 1.2 Mb/s | 10 ms | 1200
F2 | 99.5% | 100 Kb/s | N/A | 550
F3 | 99.5% | 15 Kb/s | 100 ms | 100
CF1 | 99.95% | 500 Kb/s | 100 ms | 1750
CF2 | N/A | 100 Kb/s | 100 ms | 2100
CF3 | N/A | 3 Mb/s | 100 ms | 50
Total Budget for Network Project—$750K

Figure 4.33: Example flow information for prioritization.
Flow ID | Performance Requirements |  |  | Number of Users | Budget | Priority
 | Reliability | Capacity | Delay
CF2 | N/A | 100 Kb/s | 100 ms | 2100 | $274K | 1
CF1 | 99.95% | 500 Kb/s | 100 ms | 1750 | $228K | 2
F1 | N/A | 1.2 Mb/s | 10 ms | 1200 | $157K | 3
F2 | 99.5% | 100 Kb/s | N/A | 550 | $72K | 4
F3 | 99.5% | 15 Kb/s | 100 ms | 100 | $13K | 5
CF3 | N/A | 3 Mb/s | 100 ms | 50 | $6K | 6
Total Budget for Network Project—$750K

Figure 4.34: Flows prioritized by number of users served.

In Figure 4.34 the flows are prioritized based on the number of users the flow supports. This information is determined from the requirements specification and the requirements map, by comparing user, application, and device requirements and mapping them to common flows. For this network there is a funding level ($750K), which is distributed to each flow based on the number of users supported.

Another example prioritizes flows based on performance requirements, in this case reliability. Figure 4.35 shows a set of flows prioritized this way. In this example there are three levels of reliability: 99.95%, 99.5%, and N/A (not applicable). Budget allocations for each level are as follows: highest level, one half of budget; middle level, three eighths of budget; and lowest level, one eighth of budget.

Flow ID | Performance Requirements |  |  | Number of Users | Budget | Priority
 | Reliability | Capacity | Delay
CF1 | 99.95% | 500 Kb/s | 100 ms | 1750 | $375K | 1
F2 | 99.5% | 100 Kb/s | N/A | 550 | $141K | 2
F3 | 99.5% | 15 Kb/s | 100 ms | 100 | $141K | 2
F1 | N/A | 1.2 Mb/s | 10 ms | 1200 | $31K | 3
CF2 | N/A | 100 Kb/s | 100 ms | 2100 | $31K | 3
CF3 | N/A | 3 Mb/s | 100 ms | 50 | $31K | 3
Total Budget for Network Project—$750K

Figure 4.35: Flows prioritized by reliability.

Funding can be applied to this list of flows in various ways. It can be applied based on the level of reliability. In this case all flows with equal levels of reliability get equal amounts of funding; this allocation can then be refined by including another parameter, such as the users or applications supported.

How per-flow funding relates to purchasing equipment is discussed in Chapter 10.


4.9 The Flow Specification

The results of identifying, defining, and describing flows are combined into a flow specification, or flowspec. A flow specification lists the flows for a network, along with their performance requirements and priority levels (if any). Flow specifications describe flows with best-effort, predictable, and guaranteed requirements, including mission-critical, rate-critical, real-time, interactive, and low and high performance. The flow specification combines performance requirements for composite flows when there are multiple applications requirements within the flow. It can also be used to combine requirements for all flows in a section of a path. There is much information imbedded within a flow specification.

Flow specifications can take one of three types: one part, or unitary; two part; or multipart. Each type of flowspec has a different level of detail depending on whether the flows have best-effort, predictable, and/or guaranteed requirements.

A one-part flowspec describes flows that have only best-effort requirements. A two-part flowspec describes flows that have predictable requirements and may include flows that have best-effort requirements. A multipart flowspec describes flows that have guaranteed requirements and may include flows that have predictable and/or best-effort requirements (Figure 4.36).

Flow Specification Type | Types of Flows | Performance Description
One-Part | Best-Effort Individual and Composite | Capacity Only
Two-Part | Best-Effort and Stochastic, Individual and Composite | Reliability, Capacity, and Delay
Multipart | Best-Effort, Stochastic, and Guaranteed, Individual and Composite | Reliability, Capacity, and Delay

Figure 4.36: Descriptions of flow specifications.

These flow specifications range in complexity. One-part and two-part flowspecs can be relatively straightforward, whereas multipart flowspecs can be quite complex. Two-part flowspecs are usually a good balance between ease of development and amount of detail. Many networks can be adequately represented with a one-part flowspec when performance requirements and flows are not well understood.

As networks become integrated into the rest of the system, however, flows will incorporate more reliability and delay requirements and the two-part and multipart flowspecs can better represent the network. This is the case today for many networks. In developing the flowspec, we will use the information in the requirements specification and requirements map as the basis for flows and apply the methods described in this chapter to identify and describe flows.

4.9.1 Flowspec Algorithm

Flowspecs are used to combine performance requirements of multiple applications for a composite flow or multiple flows in a section of a path. The flowspec algorithm is a mechanism to combine these performance requirements (e.g., capacity, delay, and RMA) for flows in such a way as to describe the optimal composite performance for that flow or group of flows.

The flowspec algorithm applies the following rules:

  1. Best-effort flows consist only of capacity requirements, so only capacities are used in best-effort calculations.

  2. For flows with predictable requirements, we will use all available performance requirements (capacity, delay, and RMA) in the calculations. Performance requirements will be combined for each characteristic to maximize the overall performance of each flow

  3. For flows with guaranteed requirements, we will list each requirement (as an individual flow), not combining them with other requirements.

The first condition is based on the nature of best-effort traffic—that it is unpredictable and unreliable. RMA and delay requirements cannot be supported in a best-effort environment. The best that can be expected is that capacity requirements may be supported through capacity planning (also known as traffic engineering) or overengineering the capacity of the network to support these requirements.

The second condition is at the heart of the flowspec—that for each performance characteristic, capacity, delay, and RMA, the requirements are combined to maximize the performance of the flow or group of flows. How the requirements are combined to maximize performance is discussed later in this chapter.

The third condition is based on the nature of guaranteed requirements. Since flows with such requirements must be supported end-to-end, their requirements are kept separate so that we can identify them in the network architecture and design.

When a one-part flowspec is developed (for flows with best-effort requirements), capacities of the flows are combined. There should be no RMA or delay requirements for these flows. Capacities are added together, forming a total best-effort capacity (CBE), as shown in Figure 4.37.

Click To expand
Figure 4.37: One-part flow specification.

A two-part flowspec builds on a one-part flowspec, adding predictable capacities, delay, and RMA. When a two-part flowspec is developed (for flows with best-effort and predictable requirements), the best-effort flows are combined in the same way as for the one-part flowspec. For the predictable requirements, the capacities are added together, as with the best-effort flows, so that the flowspec has a total capacity for best-effort flows (CBE) and another capacity for predictable flows (CP). For the delay and RMA requirements for predictable flows, the goal is to maximize each requirement. For delay, the minimum delay (i.e., the highest-performance delay) of all of the delay requirements is taken as the predictable delay (DP) for the flowspec, and the maximum RMA (i.e., the highest-performance RMA) of all of the RMA requirements is taken as the predictable RMA (RP) for the flowspec. Figure 4.38 illustrates this for a two-part flowspec.

Click To expand
Figure 4.38: Two-part flow specification.

A multipart flowspec is the most complex of the flowspecs, building on a two-part flowspec to add guaranteed requirements. Best-effort capacity, predictable capacity, delay, and RMA are generated in the same fashion as for a two-part flowspec, and each set (i) of guaranteed performance requirements is added individually (shown as Ci, Ri, Di) to the flowspec, as shown in Figure 4.39.

Click To expand
Figure 4.39: Multipart flow specification.

Sets of guaranteed performance requirements (Ci, Ri, Di) are listed individually in the flowspec to show that they will be supported as individual requirements and not grouped with other requirements. This is necessary for us to be able to fully support each guaranteed requirements throughout the network.

4.9.2 Capacity and Service Planning

Capacity and service plans are written descriptions of the network performance required for the flows that are described in the flowspec. A capacity plan describes network performance in terms of capacity only. It is used in conjunction with a one-part flowspec. A service plan describes network performance in terms of sets of capacity, delay, and RMA. It is used in conjunction with two-part and multipart flowspecs.

Whereas a flowspec lists flows and combines their performance requirements, capacity and service plans describe what may be needed to support such requirements. As we will see in Chapter 8, there are many mechanisms that we may choose to support performance requirements in the network.


4.10 Example Application of Flow Analysis

We will now bring the concepts of flow analysis together for an example network, in this case a network to support computing and storage management. For this network project, the computing and storage devices already exist in multiple buildings on a campus. The buildings and devices that will be using this network for computing and storage management are shown in Figure 4.40.

Click To expand
Figure 4.40: Building and device locations for example.

From the requirements analysis process, we have been able to determine that this network has four types of flows:

Type 1: Flows between high-performance computing devices. There are compute servers that are the high-performance devices for this network. The first type of flow consists of traffic flows between these devices. Flows are sometimes (approximately 10% of the time) synchronized between pairs of devices. At other times, these devices may draw data from the local data store of another computing device, from the storage server at the Main Engineering building, or request a computing or data management task from a device. Most computing tasks are controlled from Main Engineering.

Type 2: Data migration from computing to storage at Main Engineering. These flows may be from each compute server as its task is completed, from the local data store at each compute server at a specific time, or from the compute server at Main Engineering at the completion of a combined (multiserver) task.

Type 3: Data migration to external server. Final data sets, or extracts of final data sets, are pushed from the Main Engineering storage server to a storage server at a building where external (Internet) access is managed. Data at this external access server are used to feed other campuses and for remote (off-site) data archival.

Type 4: Data archival and Internet access. These are flows from the external access server to users on the Internet, as well as flows to an off-site archival server.

These flow types are added to our map and are shown in Figure 4.41.

Click To expand
Figure 4.41: Map with flow types added.

From discussions with various users of these applications, we learned that flows usually run in this order: type 1, type 2, type 3, and type 4. For flow type 1, a Main Engineering compute server may act as a server for the compute servers in buildings A through C, and getting data from the storage servers in the Main Engineering building. This follows a hierarchical client-server flow model. Compute servers from buildings A through C and Main Engineering may also act as synchronized peers, using a distributed-computing flow model.

From discussions with engineering users, we found that the computing application runs in either batch or interactive mode, from about 10 minutes to several hours, generating files of sizes ranging from 1 to 2 MB (synchronization, or sync, files), 10 to 100 MB (interactive updates), and 100 MB to more than 1 GB for final data sets.

Interactivity for the computing application is the ability to steer or direct the computation. This requires synchronization on the order of human response time (HRT) (100 ms) and updates on the order of 1 second. Users expect to have up to two tasks running concurrently.

For flow type 2, data are stored at the storage servers in Main Engineering. Data can be from interactive updates, final data sets, and extracts (selected subsets of the final data set). Data also migrate from local stores at each computer server, usually every few hours.

For flow type 3, full data sets and extracts of the data sets are migrated to the external access server. Extracts are approximately 80% of the size of a full data set. Data sets are migrated hourly.

For flow type 4, users from other campuses, via the Internet, access data. Data sets are archived at an off-site facility. The system is expected to support the download of a full final data set within a few minutes.

Performance Envelope from Requirements Analysis

Flows of type 1 involve the frequent passing of 1- to 2-MB sync files with delays on the order of HRT, 10- to 100-MB update files on the order of 1 second, and final data sets of 500 MB to 1 GB on the order of minutes to hours, with up to two tasks running concurrently. From this information, we can estimate a range for capacity performance for these flows. Each of these flows is multiplied by 2 for concurrency.

Sync files: (1 to 2 MB)(8 b/B)(2 concurrent tasks)/10-1s | = | 160 to 320 Mb/s
Update files: (10 to 100 MB)(8 b/B)(2 concurrent tasks)/1 s | = | 160 Mb/s to 1.6 Gb/s
Final data sets: (500 to 1000 MB)(8 b/B)(2 concurrent tasks)/(102 to 104 s) | = | 800 Kb/s to 160 Mb/s

Type 2 flows involve migrating (pushing) updates, final data sets, and extracts. The delay characteristics of these flows are much less strict than those for the computing function, with delays ranging from 10 to 104 seconds.

Update files: (10 to 100 MB)(8 b/B)/(10 to 104 s) 8 Kb/s to 80 Mb/s Final data sets: same as for flow type 1

The performance envelope for final data sets, updates, and synchronization files is shown in Figure 4.42.

Click To expand
Figure 4.42: Performance envelope for example.

Flow Models

For flow type 1 between computer servers and the Main Engineering storage servers, flows can follow distributed-computing and hierarchical client-server computing flow models, as shown in Figure 4.43.

Click To expand
Figure 4.43: Flow models for flow type 1.

In the distributed-computing model, each device can act as a data source and as a data sink and data transfer is synchronized between devices at about 100 ms. In the hierarchical client-server model, data sets can flow from the storage server to the compute servers in Main Engineering, which then pass down to compute servers in Buildings A through C. There is no synchronization for this model.

Flow type 2 consists of data pushes from each compute server to the storage server in Main Engineering. Each compute server is a data source, and the Main Engineering storage server is a data sink (Figure 4.44).

Click To expand
Figure 4.44: Flow model for flow type 2.

For flow type 3, the storage servers in Main Engineering are data sources and the external access server is a data sink (Figure 4.45).

Click To expand
Figure 4.45: Flow model for flow type 3.

For flow type 4, a client-server flow model exists between external users of the data, including off-site archival, and the external access server (Figure 4.46).

Click To expand
Figure 4.46: Flow model for flow type 4.

Flow Map

Figure 4.47 is an example of a flow map that describes flows between buildings. Note that all devices have been removed from this map. This is often done for larger networks because the number of devices on a map can become unwieldy. Also, a flow aggregation point has been added between Buildings A through C and Main Engineering. This is done to show the aggregated performance requirements at Main Engineering (flow F4).

Click To expand
Figure 4.47: Flow map for example.

For the flow map shown in Figure 4.47, flows F1, F2, and F3 have the same performance requirements, consisting of flow types 1 and 2. Flow F4 is an aggregate of flows F1, F2, and F3 (flow types 1 and 2). Flow F5 consists of flow type 3, and flows F6 and F7 are flows of flow type 4.

Next, we combine the performance requirements from each of the flow types and apply them to flows F1 through F7, as shown in Figure 4.48.

Flow ID

Performance Requirements

Capacity (Mb/s)

Delay (ms)

F1—Flow Type 1

  • Synchronization Files

320

100

  • Update Files

1600

1000

  • Final Files

160

105

  • Result for Flow Type 1

1600

100

F1—Flow Type 2

  • Update Files

80

104

  • Final Files

160

105

  • Result for Flow Type 2

160

104

Result for F1

1760

100

Result for F2

1760

100

Result for F3

1760

100

F4—Flow Type 1

1600

100

F4—Flow Type 2

  • Update Files

320

104

  • Final Files

640

105

  • Result for Flow Type 2

640

104

Result for F4

2240

100

Result for F5

16

103

Result for F6

80

102

Result for F7

16

103

Figure 4.48: Performance requirements for flows.

When these performance requirements are added to the flow map from Figure 4.47, we get Figure 4.49. Two performance profiles (P1 and P2) were generated for multiple flows: P1 for flows F1, F2, and F3; and P2 for flows F5 and F7.

Click To expand
Figure 4.49: Performance requirements added to flow map.

A two-part flowspec for each flow that has a performance profile of P1 (F1, F2, and F3) would look like Figure 4.50.

Click To expand
Figure 4.50: Two-part flowspec for each flow with performance profile P1.


4.11 Conclusion

Flow analysis takes an end-to-end perspective of network performance requirements, combining capacity, delay, and RMA requirements into a specification that will be used as input to the network architecture and design to evaluate and help select technologies and interconnectivity strategies for the network. In building the flow specification, we use various techniques, including data sources, data sinks, and flow models, to identify and determine individual and composite flows, as well as critical flows.

Flow analysis is the final part of the analysis process. We began this process by gathering, deriving, managing, and tracking requirements for the network, from users, applications, devices, and networks that will be part of the planned network. In developing requirements for the network, we considered performance requirements (in terms of capacity, delay, and RMA) and the many ways to categorize requirements for users, applications, devices, and networks. This information, along with initial conditions, problem definitions, and goals, was collected in the requirements specification and mapped out in a requirements map.

Performance requirements, on a per-application basis or grouped by user, application, device, or network, are added to the directionality, hierarchy, and interconnectivity of traffic flows to characterize them. Some tools, such as data sources, data sinks, flow models, and flow aggregation points, can be used to help us determine which flows are important in a network and where flows are likely to occur. You are encouraged to develop other tools to aid in analyzing flows or modify those presented in this book to fit your needs.

Although flow analysis is presented here as part of the overall analysis process, in preparation to architect and design a network, it should be noted that flow analysis can be performed on any network, regardless of what state it is in. Notice that throughout the flow analysis process, no network technologies, topologies, or underlying infrastructure were shown or mentioned. Flow analysis allows us to separate traffic movement and performance requirements from an existing network, giving us the freedom to determine what flows should look like when the network does not restrict movement or performance. If you analyze flows on an existing network (regardless of whether you are developing a new network or upgrading the existing network), the results of this analysis will indicate whether the existing network needs to be modified to fit the traffic flows.

Now that we have an idea of what to expect of the network, in terms of requirements and flows, we are prepared to begin the process of network architecture.


4.12 Exercises

  1. Show flows for each set of devices and applications listed here. Label each as either a unidirectional or a bidirectional flow.

    1. Client-server application: downstream (from server to client), 1.2 Mb/s capacity; upstream (from client to server), 15 Kb/s capacity

    2. Streaming video (User Datagram Protocol) from video server to a subscriber's PC: 300 Kb/s capacity, 40-ms delay (one way).

    3. Downloading pages from the Web: downstream, 250 Kb/s capacity, 5-second delay; upstream, 100 Kb/s capacity

    4. Transaction processing from point-of-sale (PoS) machine to server: upstream (from PoS machine to server), 30 Kb/s capacity, 100-ms round-trip delay; downstream, 50 Kb/s capacity

  2. Devices can act as both data sources and data sinks depending on the application and flow. Which of the following devices (for the applications given) are data sinks? Which are data sources?

    1. A storage device receiving streaming video from a camera

    2. A video-editing unit, using video from the storage device in part a

    3. A Web server and its clients

    4. A storage disk farm

  3. Which flow models apply to each set of flows described here?

    1. Users on the Internet accessing the same Web server

    2. Forty workstations processing batch jobs overnight, managed by a central mainframe

    3. Email use across the Internet

    4. A transaction-processing application, authorizing credit card transactions between a company's retail stores and its headquarters

  4. For each of the examples in Exercise 3, give the most likely direction(s) for the flows described by each flow model.

  5. Develop a flow model for real-time/near-real-time flows. How would you characterize the flows for this model? What are likely data sources and sinks? Apply your model to a video conferencing application.

  6. You are developing a network for a company's online transaction-processing (OLTP) application (e.g., a retail sales network). Its current system is a mainframe that has several terminals connected to it, either directly or through a terminal server, as in Figure 4.51. The company is moving to a hierarchical client-server network, where there will be multiple regional database servers, each acting in a client-server fashion and updating each other's regions via a database manager, as in Figure 4.52.

    Click To expand
    Figure 4.51: Mainframe environment for OLTP application.

    Click To expand
    Figure 4.52: Hierarchical client-server environment for OLTP application.

    1. Show the probable data sources and sinks for both environments.

    2. How does migrating from the mainframe environment to the hierarchical client-server environment modify the traffic flows in the network?

    3. In what ways does the network environment improve the traffic flows?

    4. What are some of the potential trade-offs between the two environments, for example, in security, management, and performance?


Chapter 5: Network Architecture

Network architecture is the process of developing a high-level, end-to-end structure for the network. This includes the relationships within and between major architectural components of the network, such as addressing and routing, network management, performance, and security. Network architecture is the next part of the process of developing our network, and as we will see, it is key in integrating requirements and flows into the structure of a network.

5.1 Objectives

In this chapter, you will learn about network architecture—what is contained within the architecture of a network and how to develop this architecture. We will discuss the concept of relationships within and between components of the architecture. You will learn the factors that make up these relationships and how they apply to each architectural component. We will also present several architectural models for you to use as a starting point in developing your network architecture.

This chapter introduces several concepts around network architecture, some of which may be new to you. In addition, many terms for addressing and routing, performance, network management, and security are presented in this chapter but will be detailed in Chapters 6 through 9.


5.2 Preparation

To be able to understand and apply the concepts in this chapter, you should be familiar with the basic concepts and mechanisms of performance (e.g., quality of service [QoS]), security and privacy, network management, and routing and addressing. Some recommended sources of information include:

  • Internet QoS: Architectures and Mechanisms for Quality of Service, by Zheng Wang, Morgan Kaufmann Publishers, March 2001

  • Designing Quality of Service Solutions for the Enterprise, by Eric D. Siegel, John Wiley & Sons, October 1999

  • The CERT(R) Guide to System and Network Security Practices, by Julia H. Allen, Addison-Wesley Publishing, June 2001

  • Simple Network Management Protocol (SNMP), STD 0015,[1] by J. D. Case, M. Fedor, M. L. Schoffstall, C. Davin, May 1990

  • Routing in the Internet, by Christian Huitema, Prentice Hall, January 2000

[1]All Internet Engineering Task Force requests for comments and STDs can be found at www.ietf.org.


5.3 Background

What is network architecture? In general, architecture is the art and science of designing and constructing or the discipline of dealing with the principles of design and building. In terms of network architecture, this applies to the art and science in designing and constructing a network. A more specific definition for network architecture is an understanding of the relationships between (architectural) components of the network. Network architecture also guides the technical design of the network through applying sets of high-level design principles. Such high-level design principles act upon the building blocks of the network to develop overall structure and function. We will discuss the nature of these relationships, design principles, and building blocks in this chapter.

Defining the building blocks is essential to the success of network architecture. It is intuitive to consider these to be the physical entities (e.g., routers, switches, multiplexers, servers) in the network, especially since they are readily mapped to network technologies and purchased from vendors.

However, this common view of network architecture constrains the functions of a network (addressing/routing, security, network management, performance) to operate within this physical structure. This forces functions into suboptimal configurations, as when one function decreases or negates the effectiveness of another. For example, security mechanisms colocated with routers or switches, without consideration to routing or performance, can seriously affect those functions.

A different approach is to define the network building blocks as functional instead of physical entities. In doing so, the set of high-level design principles that constitute the network architecture are applied to how the network functions and operates.

This has several advantages over the physical approach. Network functions are closely coupled to users and their applications and devices. This allows user requirements to be directly represented in the network architecture. In fact, the success of a network can be defined by how well user, application, and device requirements are supported through these functions.

In addition, network functions, as well as user, application, and device requirements, often have a common basis in traffic flows. As part of the network architecture, the characterization of traffic flows can indicate when and where network functions will operate on common flows and thus may have an impact on each other and the overall effectiveness of the network. By focusing on functions in the network architecture, you will better understand these interactions. Interactions, both within a function and between functions, are used to optimize the network architecture.

In this chapter we will discuss how to describe, understand, and optimize the functions of a network, their interactions within the network, and how they can be meaningfully combined for that network. In this approach, each network function is developed and optimized as its own component architecture. Component architectures are then combined into a reference architecture by analyzing and optimizing interactions between components.

Since this approach focuses on network functions and their interactions, it is scalable to the largest networks. This process can be applied to the entire network or part of a network, or it can be focused on a particular function. It provides a set of architectural guidelines that can be used to formulate the technical design of a network, consistent with Internet architecture philosophies.

5.3.1 Architecture and Design

It is easy to confuse architecture and design. They are similar in many ways, and designs are often just more detailed versions of the architecture. There are, however, ways in which they differ. Figure 5.1 compares some of the similarities and differences between architecture and design.

Click To expand
Figure 5.1: Comparisons between architecture and design.

Some of these differences reflect the concept that the design is more detailed. For example, whereas the scope of architecture is typically broad, designs tend to be more focused. Network architecture will show a high-level view of the network, including locations of major or important components, whereas a network design will have details about each portion of the network or focus on a particular section of the network (e.g., storage, servers, and computing). As the design focuses on selected parts of the network, the level of detail about that part increases.

Architecture and design are similar in one important way though: They both attempt to solve multidimensional problems based on the results of the network analysis process. Figure 5.2 shows a solution space that can be made up of many variables (e.g., performance, security, and network management), and network architecture solutions are based on relationships between these variables. We will discuss these relationships throughout the architecture process.

Click To expand
Figure 5.2: Architecture and design solutions are multidimensional.

In terms of what is described, however, the architecture can differ substantially from the design. Network architecture describes relationships, whereas a design usually specifies technologies, protocols, and network devices. So that we can begin to see how the architecture and design complement each other, it is important to understand how various components of the network will work together before actually specifying the equipment to be deployed.

Another way that architecture can differ from design is in knowledge of location information. Although location is important for some parts of the architecture (e.g., external interfaces, locations of existing devices and applications), the relationships between components are generally location independent. In fact, inserting location information into the network architecture can be constraining. For a network design, however, location information is important. The design includes a sufficient amount of detail, so locations play an important part of the decision-making process.

Good network design is a process by which an extremely complex and nonlinear system is conceptualized. Even the most experienced network designer must first conceptualize a big picture and then develop the detailed designs of the components. The network architecture represents that big picture and can be developed only by creating an environment that balances the requirements of the customers with the capabilities of network technologies and the personnel that will run and maintain the system.

Not only is the network architecture necessary for a solid design, but it is also essential to sustaining the required performance over time. Network personnel must grasp the big picture and understand it to be able to make the network perform as designed. To be successful, architecture development must be approached in a systematic manner.

Poor network architecture and design reflects the personality of a "wizard" who opens his or her bag of network tricks and pulls a couple out. Network architecture and design development is no longer simple enough that tricks will work; it must be done in a systematic and reproducible manner. Even if a complex network architecture/ design is "tricked" into existence, it cannot be maintained. Smart customers are beyond the stage at which they would hire a "wizard" to work magic. They have been burned (or heard about being burned) by the unpredictability of this behavior. Now that network services are essential to business, predictable, reliable, high-quality performance is what customers are seeking.


5.4 Component Architectures

Component architecture is a description of how and where each function of a network is applied within that network. It consists of a set of mechanisms (hardware and software) by which that function is applied to the network, where each mechanism may be applied, and a set of internal relationships between these mechanisms.

Each function of a network represents a major capability of that network. This book explores four such functions: addressing/routing, network management, performance, and security. Other general functions, such as infrastructure and storage, could also be developed as component architectures, and there can certainly be functions specific to each network that you may wish to develop.

Mechanisms are hardware and software that help a network achieve each capability. Some example mechanisms are shown in Figure 5.3 and are examined in detail in Chapters 6 through 9, which deal with component architectures.

Function | Description of Capability | Example Subset of Mechanisms Used to Achieve Capability
Addressing/Routing | Provides robust and flexible connectivity between devices | Addressing: ways to allocate and aggregate address space Routing: routers, routing protocols, ways to manipulate routing flows
Network Management | Provides monitoring, configuring, and troubleshooting for the network | Network management protocols Network management devices Ways to configure network management in the network
Performance | Provides network resources to support requirements for capacity, delay, and RMA | Quality of service Service-level agreements Policies
Security | Restricts unauthorized access, usage, and visability within network to reduce the threat and effects of attacks | Firewalls Security policies and procedures Filters and access control lists

Figure 5.3: Functions, capabilities, and mechanisms.

Internal relationships consist of interactions (trade-offs, dependencies, and constraints), protocols, and messages between mechanisms, and they are used to optimize each function within the network. Trade-offs are decision points in the development of each component architecture. They are used to prioritize and decide which mechanisms are to be applied. Dependencies occur when one mechanism relies on another mechanism for its operation. Constraints are restrictions that one mechanism places on another. These relationship characteristics help describe the behaviors of the mechanisms within a component architecture, as well as the overall behavior of the function itself.

Developing a component architecture consists of determining the mechanisms that comprise each component, how each mechanism works, and how that component works as a whole. For example, consider some of the mechanisms for performance: QoS, service-level agreements (SLAs), and policies. To determine how performance will work for a network, we will need to determine how each mechanism works and how they work together to provide performance for the network and system. In Figure 5.4, QoS is applied at each network device to control its resources in support of SLAs and policies; SLAs tie subscribers to service levels, and policies (usually located at one or more databases within the network) provide a high-level framework for service levels, SLAs, and QoS.

Click To expand
Figure 5.4: Examples of performance mechanisms in a network.

Interactions within a component are based on requirements that mechanisms have to communicate and operate with each other. Using the previous example for performance, we would determine whether there are any information flows between QoS, SLAs, and policies. If such flows exist (and usually they do), we would determine where and how these flows occur. This is important to know, for when we are developing an architecture for a component, its communications requirements within that component will help drive that architecture. Figure 5.5 gives an example of where interactions occur between performance mechanisms.

Click To expand
Figure 5.5: Interactions between performance mechanisms.

Trade-offs are decision points in the development of each component; they are used to prioritize and choose between features and functions of each and to optimize each component's architecture. There are often several trade-offs within a component, and much of the refining of the network architecture occurs here. For example, a common trade-off in network management is in choosing between centralizing and distributing management capabilities. As mentioned in Chapter 1, trade-offs are fundamental to network architecture and network design. We will, therefore, spend much time on trade-offs in this chapter and throughout the rest of the book.

Dependencies are requirements that one mechanism has on one or more other mechanisms in order to function. Determining such dependencies will help us to decide when trade-offs are acceptable or unacceptable. For example, there are dependencies between addressing and routing, as proper routing function will depend on how internal and external addressing is done.

Constraints are a set of restrictions within each component architecture. For example, SLAs are constrained by the type and placement of QoS within the network. Such constraints are useful in determining the boundaries under which each component operates.

Whereas the functions described in this chapter are addressing/routing, network management, performance, and security, there are often other functions, such as network storage, computing, or application services, that can also be described by this component architecture approach. Functions may be defined by you and may be specific to the network on which you are working. Experience has shown that addressing/routing, network management, performance, and security are common across most networks. By developing the relationships between these functions, we begin to develop a highlevel, end-to-end view of the network and system.

Developing component architectures requires input, in terms of sets of user, application, and device requirements; estimated traffic flows; and architectural goals defined for each network. For example, user, application, and device requirements for performance and security are used as criteria to evaluate mechanisms for the performance and security component architectures. This input forms a common foundation for all network functions, from which all component architectures are developed. Figure 5.6 illustrates that component architectures, requirements, flows, and goals are all interwoven through the reference architecture.

Click To expand
Figure 5.6: Component architectures and the reference architecture are derived from network requirements, flows, and goals.

Based on the requirements, flows, and goals for the network, we will evaluate a set of candidate mechanisms for each function and choose the desired mechanisms.

To facilitate determining where each mechanism may be applied, the network is divided into regions. Network functions have a common basis in traffic flows; thus, characterizing regions by traffic flows allows each region to be applied in a similar fashion to all functions.

Commonly used regions include access (edge), distribution, core (backbone), external interfaces, and demilitarized zones (DMZs). From a traffic flow perspective, access regions are where most traffic flows are generated and terminated. Distribution regions are where traffic flows are aggregated and terminated for common services, such as application or storage servers. Core regions provide transit for aggregates of traffic flows; individual traffic flows are rarely generated or terminated in this region. External interfaces or DMZs are aggregation points for traffic flows external to that network.

The characteristics of each region help identify where mechanisms are applied. For example, since traffic flows are often generated and terminated at access regions, performance mechanisms that work on a per-flow basis, such as access control and traffic shaping, would apply to these regions. In the core region, where traffic flows are aggregated, performance mechanisms that work on groups or classes of flows, such as differentiated services, would apply.

Once mechanisms have been chosen and applied, we can then determine and analyze the internal relationships between these mechanisms.

In practice, mechanisms, locations, and relationship characteristics are listed in tabular form, with one set of tables for each component architecture. An example of internal relationships, in this case the set of dependencies between performance mechanisms, is presented in Figure 5.7.

 | Dependencies between Performance Mechanisms
 | QoS | SLAs | Policies
QoS |  | QoS dependencies on SLAs, e.g., QoS at network devices may need to enforce SLA values | QoS dependencies on policies, e.g., QoS at network devices may need to enforce policies
SLAs | SLA dependencies on QoS, e.g., can an SLA be enforceable via available QoS mechanisms? |  | SLA dependencies on policies, e.g., SLAs may need to map to network policies
Policies | Policy dependencies on QoS, e.g., can a policy be enforceable via available QoS mechanisms? | Policy dependencies on SLAs |

Figure 5.7: Sample chart for listing dependencies between performance mechanisms.

Each characteristic should have its own chart, showing whether or not it applied, and if it did apply, how it would work between each of the components. For example, let's consider a chart on dependencies. In developing this chart, we would start by looking at mechanisms for a particular component, for example, performance. We would consider any dependencies between mechanisms within each component.

We would continue down the list, doing the same thing for each type of interaction. We will explore these relationships in detail in Chapters 6 through 9.

As we go through the Sections 5.4.1 through 5.4.4, many terms will be introduced for the mechanisms of each network function. Although each mechanism is presented briefly in this chapter, we will discuss them in detail over the next four chapters.

In developing each component architecture, we will need to consider the dynamic nature of networks. For example, how will the network be reconfigured to handle a security attack? What happens when traffic flows change and congestion occurs? How much of each function can be automated?

Each component architecture will have policies associated with it. Security, routing, performance, and network management policies can have elements in common. Documenting policies early in the architectural process will help you understand the relationships between component architectures.

5.4.1 Addressing/Routing Component Architecture

Addressing is applying identifiers (addresses) to devices at various protocol layers (e.g., data link and network), whereas routing is learning about the connectivity within and between networks and applying this connectivity information to forward IP packets to their destinations.

The addressing/routing component architecture describes how user and management traffic flows are forwarded through the network and how hierarchy, separation, and grouping of users and devices are supported.

This component architecture is important; it determines how user and management traffic flows are propagated throughout the network. As you can imagine, this will be closely tied to the network management architecture (for management flows) and performance architecture (for user flows). This architecture also helps determine the degrees of hierarchy and interconnectivity in the network, as well as how areas of the network are subdivided.

Several addressing and routing mechanisms could be considered for this component architecture. From an addressing perspective, mechanisms include subnetting, variable-length subnetting, supernetting, dynamic addressing, private addressing, virtual LANs (VLANs), IP version 6 (IP6), and network address translation (NAT). From a routing (forwarding) perspective, mechanisms include switching and routing, default route propagation, classless interdomain routing (CIDR), multicasts, mobile IP, route filtering, peering, routing policies, confederations, and Internet Gateway Protocol (IGP) and External Gateway Protocol (EGP) selection and location.

Depending on the type of network being developed, the set of candidate addressing and routing mechanisms for a component architecture can be quite different. For example, a service-provider network may focus on mechanisms such as supernetting, CIDR, multicasts, peering, routing policies, and confederations, whereas the focus of a medium-sized enterprise network would more likely be on classful or private addressing and NAT, VLANs, switching, and the selection and locations of routing protocols (particularly IGPs).

In terms of addressing, classful addressing is applying predetermined mask lengths to addresses in order to support a range of network sizes. Subnetting is using part of the device (host) address space to create another layer of hierarchy. Variable-length subnetting is subnetting in which multiple subnet masks are used, creating subnets of different sizes. Supernetting is aggregating network addresses, by changing the address mask, to decrease the number of bits allocated to the network; dynamic addressing is providing addresses on demand. Private IP addressing is using IP addresses that cannot be advertised and forwarded by network and user devices in the public domain (i.e., the Internet). VLANs are addresses that can be dynamically changed and reconfigured to accommodate changes in the network. IP6 is the next generation of IP addresses. NAT is the mapping of IP addresses from one realm to another. Typically this is between public and private address spaces.

In terms of forwarding, switching and routing are common forwarding mechanisms. Default route propagation is a technique used to inform the network of the default route (or route of last resort). CIDR is routing based on arbitrary address mask sizes (classless). Multicasts are packets targeted toward multiple destinations. Mobile IP is providing network (IP) connectivity for devices that move or roam or are portable. Route filtering is the technique of applying filters (statements) to hide networks from the rest of an autonomous system or to add, delete, or modify routes in the routing table, Peering is an arrangement between networks or autonomous systems (peers) to mutually pass traffic and adhere to routing policies, which are highlevel statements about relationships between networks or autonomous system, and IGP and EGP selection and location, which is comparing and contrasting IGPs in order to select the appropriate protocols for the network and decide where to apply them in the network.

Two types of interactions between mechanisms are predominant within this component architecture: trade-offs between addressing and routing mechanisms and trade-offs within addressing or within routing. Addressing and routing mechanisms influence the selection of routing protocols and where they are applied. They also form an addressing hierarchy upon which the routing hierarchy is overlaid.

Areas of the network where dynamic addressing, private addressing, and NAT mechanisms are applied will affect how routing will (or will not) be provided to those areas.

The addressing/routing component architecture will be discussed in detail in Chapter 6.

5.4.2 Network Management Component Architecture

Network management is providing functions to control, plan, allocate, deploy, coordinate, and monitor network resources. Network management is part of most or all of the network devices. As such, the network management architecture is important because it determines how and where management mechanisms will be applied in the network. It is likely that the other architectural components (e.g., IT security) will require some degree of monitoring and management and will interact with network management.

The network management component architecture describes how the system, including the other network functions, is monitored and managed. This consists of an information model that describes the types of data that are used to monitor and manage each of the elements in the system, mechanisms to connect to devices in order to access data, and the flows of management data through the network.

Network management mechanisms include monitoring and data collection; instrumentation to access, transfer, act upon, and modify data; device and service configuration; and data processing, display, and storage. Network management mechanisms include:

  • Monitoring

  • Instrumentation

  • Configuration

  • FCAPS components

  • In-band and out-of-band management

  • Centralized and distributed management

  • Scaling network management traffic

  • Checks and balances

  • Managing network management data

  • Management information base (MIB) selection

  • Integration into operations support system (OSS)

Whereas monitoring is obtaining values for end-to-end, per-link, and per-element network management characteristics, instrumentation is determining the set of tools and utilities needed to monitor and probe the network for management data. Configuration is setting parameters in a network device for operation and control of that element. FCAPS is the set of fault, configuration, accounting, performance, and security management components. In-band and out-of-band management refers to whether management data flow along the same path as user traffic or have a separate path. Centralized and distributed management refers to whether the management system is in a single hardware platform or is distributed across the network among multiple platforms. Scaling network management data is determining how much network capacity should be reserved for network management. Checks and balances is using multiple mechanisms to verify that variables are represented correctly. MIB selection is determining which MIBs to use and how much of each MIB to use. Integration into OSS refers to how the management system will communicate with higher level OSSs.

As we will see in Chapter 7, many interactions exist within the network management component. These include trade-offs of routing management traffic flows along the same paths as user traffic flows (in-band) or along separate paths (out-ofband) and centralizing all management mechanisms by placing them on a single hardware platform or distributing them throughout the network on multiple platforms.

5.4.3 Performance Component Architecture

Performance consists of the set of mechanisms used to configure, operate, manage, provision, and account for resources in the network that allocate performance to users, applications, and devices. This includes capacity planning and traffic engineering, as well as various service mechanisms. Performance may be applied at any of the protocol layers and often applies across multiple layers. Therefore, there may be mechanisms targeted toward the network layer, the physical layer, or the data-link layer, as well as at the transport layer and above.

The performance component architecture describes how network resources will be allocated to user and management traffic flows. This consists of prioritizing, scheduling, and conditioning traffic flows within the network, either end-to-end between source and destination for each flow or between network devices on a per-hop basis. It also consists of mechanisms to correlate user, application, and device requirements to traffic flows, as well as traffic engineering, access control, QoS, policies, and SLAs.

QoS is determining, setting, and acting on priority levels for traffic flows. Resource control refers to mechanisms that will allocate, control, and manage network resources for traffic. SLAs are informal or formal contracts between a provider and user that define the terms of the provider's responsibility to the user and the type and extent of accountability if those responsibilities are not met. Policies are sets (again, formal or informal) of high-level statements about how network resources are to be allocated among users.

This important architectural component provides the mechanisms to control the network resources that are allocated to users, applications, and devices. This may be as simple as determining the amount of capacity that is available in various regions of the network or as complex as determining the capacity, delay, and reliability, maintainability, and availability characteristics on a per-flow basis.

As we will discuss in detail in Chapter 8, interactions within this component architecture include the trade-offs between end-to-end and per-hop prioritization, scheduling, and conditioning of traffic flows, as well as whether flows are treated individually, are aggregated into groups, or a combination of the two. As we will see, these interactions are closely coupled at the network (IP) layer to the use of differentiated services (DiffServ) and integrated services (IntServ) within the network. Differentiated and integrated services are performance mechanisms standardized through the Internet Engineering Task Force that target individual and aggregate performance requirements.

When policies, SLAs, and differentiated services are chosen for the network, part of this component architecture describes the placement of databases for SLA and policy information, including policy decision points (PDPs), policy enforcement points (PEPs), and Diffserv edge devices.

5.4.4 Security Component Architecture

Security is a requirement to guarantee the confidentiality, integrity, and availability of user, application, device, and network information and physical resources. This is often coupled with privacy, which is a requirement to protect the sanctity of user, application, device, and network information.

The security component architecture describes how system resources are to be protected from theft, damage, denial of service, or unauthorized access. This consists of the mechanisms used to apply security, which may include such hardware and software capabilities as virtual private networks, encryption, firewalls, routing filters, and NAT.

Each of these mechanisms can be targeted toward specific areas of the network, such as at external interfaces or at aggregation points for traffic flows. In many instances, security mechanisms are deployed in regions, often termed security zones or cells, where each region or security zone represents a particular level of sensitivity and access control. Security zones may be within each other, overlapping, or completely separate, depending on the security requirements and goals for that network. We will cover security zones, as part of the security component architecture, in detail in Chapter 9.

The security and privacy architecture determines to what degree security and privacy will be implemented in the network, where the critical areas that need to be secured are, and how it will affect and interact with the other architectural components.

Security mechanisms that we will consider include:

  • Security threat analysis

  • Security policies and procedures

  • Physical security and awareness

  • Protocol and application security

  • Encryption

  • Network perimeter security

  • Remote access security

Security awareness is educating users, getting them involved with the day-to-day aspects of security in their network, and helping them understand the potential risks of violating security policies and procedures. Security policies and procedures are formal statements on rules for system, network, and information access and use to minimize exposure to security threats. Physical security is the protection of devices from physical access, damage, and theft (including isolating all or parts of the network from outside access). Protocol and application security is securing management and network protocols and applications from unauthorized access and misuse. Encryption is a security mechanism in which cipher algorithms are applied together with a secret key to encrypt data so that they are unreadable if intercepted. Network perimeter security is protecting the external interfaces between your network and external networks. And finally, remote access security is securing network access based on traditional dial-in, point-to-point sessions and virtual private network connections.

5.4.5 Optimizing Component Architectures

Determining and understanding the set of internal relationships enables you to optimize each component architecture for a particular network. This is based on input for that particular network, the requirements, estimated traffic flows, and goals for that network.

After you have chosen a set of mechanisms for a component architecture and determined possible interactions between these mechanisms, the requirements, flows, and goals for the network are used to prioritize the mechanisms and interactions.

User, application, and device requirements usually incorporate some degree of performance, security, and network management requirements. Such requirements are directly related to selecting and placing mechanisms within a component architecture, as well as prioritizing interactions.

Estimated traffic flows for the network, determined either through modeling and simulation, experience with the existing system, or via a set of heuristics, can indicate aggregation points for traffic or where high-priority flows (e.g., mission-critical, realtime, secure, or operations, administration, and maintenance) are likely to occur. By understanding the types of flows in the network and where they are likely to occur, you can develop each component architecture to focus on mechanisms that will optimally support high-priority flows.

Architectural goals for the network are either derived from requirements; determined from discussions with users, management, and staff; or taken as an extension of the scope and scale of the existing network. When goals are developed from various sources, they provide a broad perspective on which functions are most important in a network. Thus, requirements, flows, and goals strongly influence which mechanisms are preferred and where they are applied for each component architecture.


5.5 Reference Architecture

A reference architecture is a description of the complete network architecture and contains all of the component architectures (i.e., functions) being considered for that network. It is a compilation of the internal and external relationships developed during the network architecture process (Figure 5.8).

Click To expand
Figure 5.8: Process model for component architecture approach.

There can be more, less, or different component architectures than those described in this book, depending on how you choose to focus on for your network. For example, the component architecture labeled "Others" in Figure 5.8 could be an infrastructure architecture or a storage architecture. This flexibility allows you to choose those component architectures that best fit the requirements of that network.

In Figure 5.8, each component architecture defines the internal relationships for a particular function, whereas the reference architecture combines these components. As we will see, component architectures can be weighted to determine their relative priority levels.

Once the component architectures are developed for a network, their relationships with each other are then determined. These external relationships are defined by the interactions between pairs of component architectures, their trade-offs, dependencies, and constraints. Typically, all of the component architectures for a network are closely coupled to each other. This will be reflected in their external relationships.

Just as internal relationships are used to optimize each component architecture for the network, external relationships are used to optimize the sum of all component architectures. Thus, the reference architecture, developed by combining component architectures, incorporates the effects that functions have on each other.

Depending on the requirements, traffic flows, and goals for a particular network, the reference architecture is either balanced across all functions or weighted to favor one or more functions. In a network architecture that is balanced across all functions, constraints and dependencies between functions are minimized and trade-offs between functions are balanced so that no individual function is prioritized over the others.

When one or more functions are weighted in favor over others, the external relationships reflect this weighting. For example, in a network in which performance is the primary architectural goal, the external relationships between performance and the other functions would be weighted so that interactions (trade-offs in particular) favor performance.

This is a powerful capability that is missing in traditional approaches, not only because it provides the ability to decide which functions are prioritized higher than others, but also because this becomes an informed decision in which the effects on other functions and on the reference architecture are understood and documented as part of the network architecture.

Consider a network in which the set of requirements, flows, and goals indicate that low delay and jitter performance are high priority. Yet, in this same network, routing, network management, and security all affect delay and jitter performance. In traditional network architecture, the interactions between performance and the other functions are often not well understood, resulting in a network in which security, network management, and routing mechanisms increase delay and jitter, and the network does not meet its requirements or goals.

However, if each function is developed as its own composite architecture, delay and jitter can be optimized in the performance component architecture, and then this component architecture can be prioritized over the others so that when interactions are identified between performance and the other functions, performance is chosen.

5.5.1 External Relationships

To some degree, each function depends on and supports the other functions within a network, as well as the requirements from users, applications, and devices. This is reflected in the external relationships between their component architectures.

The addressing/routing component architecture supports traffic flows from each of the other functions. Based on the mechanisms used in the network management and security component architectures, their traffic flows may take separate paths from user traffic flows, a capability that must be incorporated into the addressing/routing component architecture.

In addition, routing can be configured so that traffic flows with differing performance requirements take separate paths through the network, coupling addressing/ routing with performance. This is evident in routing protocols that integrate performance mechanisms, such as multiprotocol label switching (MPLS).

Each component architecture depends on network management to support the access and transport of management data for that component. In practice, the monitoring and management of addressing/routing, performance, and security are often achieved through an integrated approach within the network management component architecture.

In this approach, network management supports flows of management data for each function equally. In some cases, however, multiple priority levels are assigned to the access and transport of management data for the various functions.

The performance component architecture provides network resources to support the other functions, as well as user, application, and device traffic flows. By understanding performance requirements at various levels of granularity (e.g., networkwide, per function, per user/application/device, or per flow), this component architecture describes how performance mechanisms are used to allocate resources at the proper level of granularity.

For example, the performance component architecture for a service-provider network may focus on traffic engineering to achieve a system-wide balance for bandwidth allocation. In addition, this network may include SLAs, access control, and traffic prioritization, scheduling, and conditioning to provide bandwidth and delay performance to select groups of users or applications.

The security component architecture supports the security and privacy requirements of each of the other functions. For addressing/routing, performance, and network management, network devices are where traffic flows are aggregated and controlled, and they often require a high degree of security, in terms of additional access controls and protocol (e.g., Simple Network Management Protocol) security.

5.5.2 Optimizing the Reference Architecture

Requirements, flows, and goals for a network are used to optimize the reference architecture, much the same way that each component architecture is optimized. However, for the reference architecture, interactions occur between pairs of component architectures. Numerous trade-offs, dependencies, and constraints occur between addressing/routing, network management, performance, and security. Some examples of common interactions between pairs of component architectures are presented in the following sections.

Interactions between Performance and Security

By their nature, security mechanisms are often intrusive, inspecting and controlling network traffic and access. Such actions require network resources and processing, increasing network delay. As security is increased, by adding more mechanisms to the network, performance is decreased. Whereas capacity can sometimes be increased to offset a decrease in performance, delay is difficult to mitigate.

When performance is high priority, particularly when there is a need to measure end-to-end performance between select users, applications, or devices, performance mechanisms may preclude the use of security in particular areas of the network. Some security mechanisms interrupt or terminate and regenerate traffic flows, seriously affecting the ability to provide end-to-end performance across a security interface. As a result, security can constrain performance mechanisms to within a security perimeter.

Interactions between Network Management and Security

Network management requires frequent access to network devices and thus is a potential security problem. Management access can be provided out-of-band via a separate management network, with its own security mechanisms. When management access is in-band, however, any additional security mechanisms for network management may affect performance for user traffic flows. When manageability is a high priority, a separate security component architecture for network management may be indicated.

Interactions between Network Management and Performance

In-band network management directly affects the performance of user traffic flows, as management traffic flows compete with user traffic flows for network resources. This is often a problem in centralized network management architectures, as all management traffic flows are aggregated to a common management device. As management traffic flows are aggregated, their network resource requirements can become quite large, particularly during periods of network problems. Thus, a trade-off of centralized management is either overengineering bandwidth, providing prioritization mechanisms for performance, or reducing performance expectations.

Interactions between Addressing/Routing and Performance

Performance can be closely coupled with routing through mechanisms such as MPLS, differentiated and integrated services, and signaling via the Resource Reservation Protocol. However, when routing protocol simplicity is a high priority, performance may be decoupled from routing. The result of this approach is a network architecture that shows how each function is optimally applied to the network, how the functions interact with each other, and how they can be balanced or prioritized in the reference architecture.

When the architectural process is completed, you will have a set of component architectures that will overlay on top of your requirements and flow maps, as shown in Figure 5.9. This set of overlays describes how each function is supported in the network, where mechanisms are to be applied, and how they interact with each other.

Click To expand
Figure 5.9: Component architectures form overlays onto requirements and flow maps.


5.6 Architectural Models

In developing the architecture for your network, you can use several architectural models as a starting point, as the foundation of your architecture, or to build on what you already have. Three types of architectural models are presented here: topological models, which are based on a geographical or topological arrangement and are often used as starting points in the development of the network architecture; flow-based models, which take particular advantage of traffic flows from the flow specification; and functional models, which focus on one or more functions or features planned for in the network. Your reference architecture will likely contain more than one architectural model.

5.6.1 Topological Models

There are two popular topological models: LAN/metropolitan-area network (MAN)/WAN and access/distribution/core models. The LAN/MAN/WAN architectural model is simple and intuitive, based on geographical and/or topological separation of networks. Figure 5.10 shows this model.

Click To expand
Figure 5.10: LAN/MAN/WAN architectural model.

The important feature of this model is that, by concentrating on LAN/MAN/WAN boundaries, a focus of this model is on the features and requirements of those boundaries and on compartmentalizing functions, services, performance, and features of the network along LAN/MAN/WAN boundaries. Both this model and the access/distribution/core model (Figure 5.11) also indicate the degree of hierarchy intended for the network. Both models can be collapsed to show fewer than three levels or expanded to show as many levels as necessary. For example, the LAN/MAN/WAN model is often used as a LAN/WAN model, or the LAN component is separated into campus, buildings, or even floors.

Click To expand
Figure 5.11: Access/distribution/core architectural model.

Interface control descriptions (ICDs) are useful in managing the development of this architectural model. ICDs define and describe LAN/MAN/WAN boundaries. This consists of the network devices, links, networks, and any other elements that are used to interconnect LANs, MANs, and WANs.

The access/distribution/core architectural model has some similarities and differences to the LAN/MAN/WAN model. It is similar to the LAN/MAN/WAN model in that it compartmentalizes some functions, services, performance, and features of the network, although not to the degree of the LAN/MAN/WAN model. The access/distribution/core model, however, focuses on function instead of location, as Figure 5.11 shows. An important characteristic of this model is that it can be used to reflect the behavior of the network at its access, distribution, and core areas.

The access area is closest to the users and their applications and is where most traffic flows are sourced and sinked. Thus, flows and requirements can be treated on an individual basis more easily than in the distribution and core areas.

The distribution area can also source and sink flows, but they are more likely to be to or from multiuser devices, such as servers or specialized devices. Few users are normally directly connected to the distribution area. As such, this area is often used to consolidate flows. As we will see, performance mechanisms that support both individual and combined flows can be used here.

The core of the network is used for bulk transport of traffic, and flows are not usually sourced or sinked at the core. Thus, any view of individual flows is lost at the core, unless it is specifically planned for (as with flows that have guaranteed requirements).

Both the LAN/MAN/WAN and access/distribution/core models are used as starting points in the network architecture, as they are intuitive and easy to apply. They can be restrictive, however, in that they place strict boundaries between areas. When applying these models, therefore, keep in mind that you may have to be creative in how you define each area so that it fits the requirements for that area.

5.6.2 Flow-Based Models

Flow-based architectural models are based on their counterparts, the flow models discussed in Chapter 4. If you used these models during the flow analysis process, it may be easy to then apply them here. Although each model has the features of its flow counterpart, it also has architectural features that were not discussed with the flow models. The flow-based models we present are as follows: peer-to-peer, client-server, hierarchical client-server, and distributed computing.

The peer-to-peer architectural model is based on the peer-to-peer flow model, in which the flow behaviors of the devices and applications are fairly consistent throughout the network. Important characteristics of this model are with the architectural features, flows, functions, and services. Since the users and applications in this model are consistent throughout the network, there are no obvious locations for architectural features. This pushed functions, features, and services toward the edge of the network, close to users and their devices, and makes flows end-to-end, between users and their devices. This resembles the core portion of the access/distribution/core model. Figure 5.12 shows this architectural model.

Click To expand
Figure 5.12: Peer-to-peer architectural model.

An example is with ad hoc networks, which lack a fixed infrastructure, forcing nodes to communicate in a peer-to-peer fashion.

The client-server architectural model also follows its flow model, but in this case there are obvious locations for architectural features, in particular where flows combine. Therefore, functions, features, and services are focused at server locations, the interfaces to client LANs, and client-server flows, as in Figure 5.13.

Click To expand
Figure 5.13: Client-server architectural model.

The characteristics of the client-sever model also apply to the hierarchical client-server architectural model. In addition to the functions, features, and services being focused at server locations and client-server flows, they are also focused at the server-server flows (Figure 5.14).

Click To expand
Figure 5.14: Hierarchical client-server architectural model.

In the distributed-computing architectural model (Figure 5.15), the data sources and sinks are obvious locations for architectural features.

Click To expand
Figure 5.15: Distributed-computing architectural model.

Flow-based models, like the topological models, are intuitive and easy to apply. Since they are associated with flows, they should map well to any flow maps you created as part of the requirements analysis process. These models are fairly general, and you may have to modify them to fit the specific requirements of your network.

5.6.3 Functional Models

Functional architectural models focus on supporting particular functions in the network. In this section we will present service-provider, intranet/extranet, single-tier/multitier performance, and end-to-end models.

The service-provider architectural model is based on service-provider functions, focusing on privacy and security, service delivery to customers (users), and billing. In this model, interactions between providers (the networks) and users are compartmentalized. Although this model represents a service-provider architecture, many enterprise networks are evolving to this model, applying it across organizations, departments, and buildings. Figure 5.16 illustrates this model.

Click To expand
Figure 5.16: Service-provider architectural model.

The intranet/extranet architectural model focuses on security and privacy, including the separation of users, devices, and applications based on secure access. Note that in this model, there can be several levels of hierarchy (security/privacy) (Figure 5.17).

Click To expand
Figure 5.17: Intranet/extranet architectural model.

The single-tier/multitier performance architectural model focuses on identifying networks or parts of a network as having a single tier of performance, multiple tiers of performance, or components of both. This model is based on results from the requirements and flow analyses, in which single-tier and multitier performance requirements are determined. Recall that for multitier performance, there are applications, devices, and users that can be the drivers for the network architecture and design, in terms of performance, whereas single-tier performance focuses on supporting (usually a majority of) applications, devices, and users that have a consistent set of performance requirements. These have two very different sets of requirements on the architecture.

Finally, the end-to-end architectural model focuses on all components in the end-to-end path of a traffic flow. This model is most closely aligned to the flow-based perspective of networking (Figure 5.18).

Click To expand
Figure 5.18: End-to-end architectural model.

Functional models are the most difficult to apply to a network because you must understand where each function will be located. For example, to apply the end-to-end model, you first have to define where end-to-end is for each set of users, applications, and devices that will be a part of end-to-end. An advantage to using functional models is that they are likely to be the most closely related to the requirements you developed during the requirements analysis process.

5.6.4 Using the Architectural Models

Typically, a few of the models from the previous three sections are combined to provide a comprehensive architectural view of the network. This is usually achieved by starting with one of the topological models and then adding flow-based and functional models as required. This is shown in Figure 5.19.

Click To expand
Figure 5.19: Functional and flow-based models complement the topological models.

The result of combining models and developing the relationships between architectural components is the reference architecture (Figure 5.20).

Click To expand
Figure 5.20: The reference architecture combines component architectures and models.

In developing a reference architecture for a network, we will use as input information from the requirements specification, the requirements map, and the flow specification, along with the architectural models and component architectures. At this point in the process we have not developed any of the component architectures, so we will focus on the architectural models. As each component architecture is developed, it is integrated into the reference architecture.

As mentioned in the previous section, we would normally start with one of the topological models—LAN/MAN/WAN or access/distribution/core—and add to that with one or more of the functional and/or flow-based models. The topological models are a good starting point, as they can be used to describe the entire network in a general fashion. Although the functional and flow-based models can also be used to describe an entire network, they tend to be focused on a particular area of the network and as such are used to add to a more general description.

Nine models have been presented in this chapter (two topological, four flowbased, and three functional models) to provide you with as many options as possible to develop your reference architecture. In practice, one or two models are typically sufficient for many networks. You may choose to apply a model to describe the entire network, with additional models for specific areas (e.g., a clientserver model for access to a server farm or a distributed-computing model for computing centers).

Consider, for example, the access/distribution/core model. The areas of this model focus on different functions in the network, such as traffic flow sources and sinks in the access network, server and/or specialized device flows in the distribution network, and bulk transport of traffic (no sources or sinks) in the core network. We would combine this model with the requirements specification and requirements map to determine which areas of the network are likely to be access, distribution, and core networks. Determining the core network is often relatively easy, but determining the distribution and access network can be more challenging. In some cases there may not be a distribution network, only access and core networks.

From a flow perspective, the core network will not source or sink any flows, the distribution network will source and sink server and specialized device flows, and the access network will source and sink generic computing device flows, as shown in Figure 5.21.

Click To expand
Figure 5.21: Access/distribution/core model from a flow perspective.

Given this perspective, we can identify potential distribution networks as locations of servers and specialized devices. We can then apply flow-based models to distribution and access networks that have client-server and hierarchical client-server flows (identified in the flow specification). As shown in Figure 5.22, these models overlap with the distribution and access networks. Usually the client-server and hierarchical client-server models apply across the distribution and access areas but may at times also apply across the core. However, even when these models apply across the core, they may not affect the architecture of the core network.

Click To expand
Figure 5.22: Where client-server and hierarchical client-server models may overlap with the access/distribution/core model.

As a general rule of thumb, Figure 5.23 shows where the functional and flowbased models may overlap with the access/distribution/core model. This figure does not imply the concurrent use of these models within one network architecture but rather where each model may overlap with the core/distribution/access model.

Click To expand
Figure 5.23: Access/distribution/core model with functional and flow-based models added.

The results of the requirements and flow analyses are used as input to the network architecture, which then lead to the development of the network design. Network architecture and design are attempts to solve nonlinear problems, and figuring out where to begin can be difficult. You cannot start at the top without some understanding of the capabilities of the individual components, and you cannot easily pick components until you understand the top-down requirements. Optimally we try to converge on an understanding of all of the pieces and then start at the top and work our way down to the individual components.

Example 5.1: Applying Architectural Models
Start example

Consider the flow map from the storage example from Chapter 4, shown in Figure 5.24.

Click To expand
Figure 5.24: Flow map from storage example in Chapter 4.

From this flow map, we can determine where flows are sourced and sinked and where servers are located. This information can be used with the access/distribution/core architectural model, with the results shown in Figure 5.25.

Click To expand
Figure 5.25: Access, distribution, and core areas defined for Example 5.1.

For this flow map, the access areas are where user devices (including the digital video camera) are located, as these devices are the primary sources of data for storage. Distribution areas are where servers are located in each campus, as these are sinks (as well as sources) of data from multiple devices. The core area is shown between buildings, as this is where bulk data transport is needed, and there are no obvious data sources or sinks. Although as shown the core area is not located at any building on the campuses, any network devices that would connect to the core area would be located at the junction between core and distribution areas at each campus.

In this example, we could also apply a distributed-computing architectural model between servers and their clients. The distributed-computing model is chosen here over the client-server model (which seems more intuitive) because the flows are primarily in the direction from the user devices to the storage servers. When this model is applied, we get Figure 5.26.

Click To expand
Figure 5.26: Distributed-computing areas defined for Example 5.1.

There are three areas where the distributed-computing model can apply in this example, one area at each campus. Note that in each area the flows within the area are from user devices to servers. At the north campus, there are also server-to-server flows, so we could have modified either the distributed-computing or the hierarchical client-server model to apply there.

End example


5.7 Systems and Network Architectures

You may find that, in the process of developing a network architecture, you may also need to develop a systems architecture. A systems architecture is a superset of a network architecture; that is, it also describes relationships, but the components are major functions of the system, such as storage, clients/servers, or databases, as well as the network. In addition, devices and applications may be expanded to include particular functions, such as storage. For example, a systems architecture may include a storage architecture, describing servers, applications, a storage-area network (SAN), and how they interact with other components of the system.

From this perspective, the systems architecture considers the total or comprehensive picture, including the network, servers/clients, storage, servers, applications, and databases (Figure 5.27). Potentially, each component in the system could have its own architecture. There are likely to be other components, depending on the environment that the network is supporting.

Click To expand
Figure 5.27: Systems architecture.

In contrast, the network architecture considers the relationships within and between each of the network architectural components (Figure 5.28).

Click To expand
Figure 5.28: Network architecture.

In this case, Figure 5.28 is one of the components of Figure 5.27. You may find that you have the start of a systems architecture with your network architecture. You can then use the network architecture as a core from which to build the systems architecture. The goal here is for you to be aware that the network architecture process may lead to areas outside of networking. When that happens, you can choose to ignore those areas, try to incorporate them into the network architecture, or expand your architecture to include a systems architecture. Chapters 6 through 9 discuss each of these network architectural components.


5.8 Conclusion

The component approach to network architecture defines the building blocks of architecture as network functions instead of physical entities. In this way, the underlying requirements, flows, and goals for the network, instead of technologies, drive the network architecture.

This approach focuses on relationships within each component and between components, providing an understanding of not only how each function operates within a network but also how it interoperates with other functions. By weighting the interactions between components (through assigning a priority to each component), you can tailor the network architecture to meet the specific needs of a network.

Component architectures and the resulting reference architecture can be further refined and validated through network modeling and simulation. This allows internal and external relationships to be studied at length and supports a logical progression through the architectural process.

Implementation of the process has identified numerous interactions between component architectures. Interactions that are particularly subtle and complex, such as in grid networking, are an evolving area of research in component architectures. Refining these interactions is an area of ongoing work.

The next four chapters focus on component architectures. The addressing and routing architecture is covered in Chapter 6, as it helps to lay the foundation for how IP is handled in the network, upon which all other component architectures depend. In Chapter 7, we cover the network management architecture and in Chapter 8, the performance architecture. We wrap up our development of component architectures with Chapter 9, the security architecture.


5.9 Exercises

  1. Network architecture defines the building blocks of a network as physical or functional entities. Give examples of physical and functional entities that you would use as building blocks for a network. How does each approach (physical and functional) differ?

  2. A network's architecture differs from its design in terms of its scope, level of detail, description, and location information. Describe how an architecture and design differ in each characteristic.

  3. A component architecture is a description of how and where each network function is applied within that network. Besides addressing/routing, network management, performance, and security, list three other possible component architectures for a network. What does each component architecture describe? Show each function and capability and give two examples of mechanisms (as in Figure 5.3).

  4. Give examples of external relationships between each of the following component architectures: addressing/routing, network management, performance, and security.

  5. What are the differences between the LAN/MAN/WAN and access/ distribution/core architectural models? Under what conditions might each be applied to a network?

  6. Consider the development of a demilitarized zone (DMZ), also known as an isolation LAN, between two different networks (two different autonomous systems managed by different organizations). The purpose of a DMZ is to separate and isolate the two networks. Briefly outline what you consider the most important addressing/routing, network management, performance, and security requirements and issues for a DMZ.

  7. For Exercise 6, what are some potential external relationships between addressing/ routing, network management, performance, and security for this DMZ? How do the component architectures need to work together to achieve the goal of effectively isolating and separating the two autonomous systems?


Chapter 6: Addressing and Routing Architecture

We begin examining component architectures with the addressing and routing architecture. IP addressing and routing are the cornerstones of a network, on which much of the performance, network management, and security component architectures are built.

6.1 Objectives

In this chapter, you will learn about the architecture for addressing and routing. We will discuss some fundamental concepts about addressing and routing for IP networks and examine various mechanisms to provide flexible and comprehensive addressing within the network, as well as to manipulate routing flows through the network. As with the other component architectures, we will discuss possible interactions within this architecture (internal relationships) and between this and other component architectures (external relationships).


6.2 Preparation

To be able to understand and apply the concepts in this chapter, you should be familiar with addressing and routing concepts for TCP/IP networks. Although the addressing mechanisms discussed in this chapter are relatively straightforward, you should have some background in IP addressing; thus, a good addressing reference is provided here. In addition, you should have some background in routing protocols, particularly Routing Information Protocol (RIP)/RIP version 2 (RIPv2), Open Shortest Path First (OSPF), and Border Gateway Protocol version 4 (BGP4). Some recommended sources of information include:

  • Everything You Wanted to Know about IP Addressing, by Chuck Semeria, available from 3Com at www.3com.com

  • Interconnections, 2nd edition, by Radia Perlman, Addison-Wesley Publishing, January 2000

  • Routing in the Internet, by Christian Huitema, Prentice Hall, January 2000

  • OSPF: Anatomy of an Internet Routing Protocol, by John T. Moy, Addison-Wesley Publishing, January 1998

  • BGP4 Inter-Domain Routing in the Internet, by John W. Stewart, Addison-Wesley Publishing, January 1999

  • Requirements for Internet Hosts—Communication Layers, STD 0003, R. Braden, ed., October 1989

  • Requirements for IP Version 4 Routers, RFC 1812, F. Baker, ed., June 1995

The host requirements and router requirements RFC and STD listed are heavy reading but thoroughly describe the vital characteristics of hosts and routers on IP networks.


6.3 Background

The final architectural component that we will discuss is a combination of addressing and routing. Although addressing and routing could be considered separate architectures, they are closely coupled in the network, so they will be considered here as parts of a single architecture. In this book the addressing and routing architecture is focused on the network (IP) layer. Addressing, however, does have elements at the link and physical layers (e.g., Ethernet and ATM addresses). Routing also has its counterparts, bridging and switching, which occur primarily at the physical, data-link, and network layers, but switching can occur at any layer in the protocol stack. Therefore, as you go through this chapter, remember that the concepts discussed can be applied at many layers in the network.

What are addressing and routing? Addressing is assigning local or global, private or public, temporary or persistent identifiers to devices. Routing consists of learning about the reachability within and between networks and applying this reachability information to forward IP packets toward their destinations. These two processes, in combination with the addressing element of the architecture, provide a complete picture of network connectivity.

In this section, we provide some fundamental concepts behind addressing and routing for your review. These fundamental concepts are necessary in understanding the rest of this chapter and are sometimes overlooked in texts on routing and routing protocols.

This chapter begins with a discussion on requirements for addressing and routing in the network architecture and then explains mechanisms (functional areas and boundaries) to establish routing flows for the network. A relationship between boundaries and routing flows is then developed, which leads to discussions on the characteristics of routing flows and how such characteristics may be manipulated. We then examine various addressing and routing mechanisms, including a comparison of popular routing protocols. This chapter then ends with the development of the addressing and routing architecture.

6.3.1 Addressing Fundamentals

A network address is an identifier used to temporarily or persistently locate a device on a network to communicate with that device. For IP, addresses consist of an address identifier and an associated mask, usually presented in dotted-decimal notation (Figure 6.1). An address mask identifies which bits in the address are considered part of the network and (by default) which bits are considered part of the device.

Click To expand
Figure 6.1: IP Addresses consist of a unique identifier and mask.

The combination of an address and its mask allows the address to be separated into a network portion and a host portion. This is important in that it enables the device to determine when an address is on the local network and when it is on a remote network. This local/remote decision is discussed in Section 6.3.2.

In this book, addresses are sometimes shown in their binary formats so that we can better understand how some of the addressing and routing mechanisms work. In this form, each decimal address is represented by its binary equivalent. Figure 6.2 shows the IP address from the previous figure, presented in binary and dotted-decimal formats.

Click To expand
Figure 6.2: An IP address in binary and dotted-decimal formats.
Example 6.1: Address and Class Calculations
Start example

For a network address of 136.178.10.1, represent this address in binary form. The bits in each octet (byte) represent a power of 2, from 20 (i.e., 1) through 27 (128), as shown here.

Click To expand

To represent the first octet of this address, 136, in binary, we can successively subtract the largest possible power of 2, until we get to 0. In this case, the largest power of 2 is 27, or 128. Subtracting 128 from 136 leaves us with 8, which is 23. Thus, 136 in binary is 10001000, as shown here:

Click To expand

Continuing in this fashion, we get the following binary representation for 136.178.10.1:

Click To expand

The numbers can be shown together as 10001000 10110010 00001010 00000001.

End example

Addresses can be local or global, private or public, temporary or persistent. Most networks implement both local and global addresses. Local addresses are those that are important in local communications, such as link-layer addresses like Ethernet. These addresses are not advertised outside of the local network. The isolation of link-layer addresses is an example of hierarchy in networking. However, for devices outside that network to communicate with devices in the network, global addresses that can be advertised outside of the local network are needed. IP addresses are used for this purpose.

IP addresses, which have traditionally been global in scope, can now be separated into public and private address spaces. Public IP addresses are those that can be advertised and forwarded by network devices in the public domain (i.e., the Internet). Private IP addresses are those that cannot be advertised and forwarded by network devices in the public domain. Private IP address space has been allocated out of previously public IP address space. Why and how this works will be explained later in this chapter.

Addresses may also be temporary or persistent. Link-layer addresses (e.g., Ethernet) are intended to be persistent for the life of the device (where device may be a network interface card). IP addresses can be either temporary or persistent, usually depending on how they are configured within the network. Temporary addresses are usually assigned using a dynamic addressing mechanism such as the Dynamic Host Configuration Protocol (DHCP). The degree to which addresses are temporary depends on how DHCP is configured for that network. Addresses may be updated each time a device becomes active on the network or may be updated periodically while a device is on the network, or an address may be assigned once (in which case it becomes persistent). Persistent addresses are usually assigned to devices as part of their overall configuration and are not updated unless changes in the network require new addresses be assigned (usually a painful process). Figure 6.3 lists these address terms and their meanings.

Address Type | Meaning
Local Addresses | Addresses that are recognized locally, at the LAN or subnet. Such addresses are usually at the data-link (e.g., Ethernet) layer.
Global Addresses | Addresses that are recognized worldwide. Such addresses are usually at the network (IP) layer.
Private Addresses | Network-layer addresses that are not routed through the public Internet. Private addresses are used in Network Address Translation (NAT).
Public Addresses | Network-layer addresses that are routed through the public Internet.
Temporary Addresses | Addresses that are assigned for a short duration of time, e.g., dynamically via the Dynamic Host Configuration Protocol (DHCP)
Persistent Addresses | Addresses that are assigned for a long duration of time or permanently configured within the device.

Figure 6.3: Address terms and meanings.

6.3.2 Routing Fundamentals

As mentioned earlier, routing is learning about reachability within and between networks and then applying this reachability information to forward IP packets toward their destinations. For routers to forward IP packets to their destinations, they first need to know what they are connected to, which networks are available, and how to get to them. This is reachability. Routers learn reachability either statically or dynamically. Routers can learn reachability statically by having this information configured into them by network personnel. Static routes, discussed later, are an example of how reachability is statically configured in a router. Typically, however, reachability is learned dynamically through the use of a routing protocol. Routing protocols, such as RIP/RIPv2, OSPF, and BGP4, provide the mechanism for routers to learn reachability.

Once routers learn about reachability within and between networks, this information is used to forward packets toward their destinations. Routers store reachability information and update it from time to time or upon a change in the state of routing in the network. A routing table, or list of routes, metrics, and how they can be reached, is a common mechanism routers use to keep such information.

Routers forward packets based on reachability. Traditionally, a router will look at the network portion of a packet's destination address to determine where it needs to be sent. The router will compare this destination to the contents of its routing table and choose the best route for that destination. If there are multiple possible routes, the best route is the one with the longest (or more explicit) match. Figure 6.4 gives an example of this.

Click To expand
Figure 6.4: Traffic is forwarded based on longest (most explicit) address match.

In this example, Company A has the address 129.29.0.0, with a network mask of 255.255.0.0, which is 16 bits in length. Company B has the address 129.99.10.0, with a network mask of 255.255.255.0, which is 24 bits in length. IP packets arriving from the Internet will be examined at ISP Z's router, where the destination addresses of these packets are compared to entries in the routing table.

In comparison of a packet's destination address to entries in a routing table, the longest match to the destination address is chosen. For example, an IP packet arriving at ISP Z with a destination address of 129.99.10.1 would match both entries in the routing table shown in Figure 6.4. When the network mask of the first entry in the routing table, 255.255.0.0, is applied to 129.99.0.0, we get 129.99 as the network. This matches the first two octets of the IP packet with 129.99.10.1 as its address. Likewise, when the network mask of the second entry in the routing table, 255.255.255.0, is applied to 129.99.10.0, we get 129.99.10 as the network. This also matches our IP packet with 129.99.10.1 as its address, but it matches the first three octets—a longer (more explicit) match. As a result, packets with a destination address of 129.99.10.1 are forwarded to ISP Y.

Usually there is also a default route, which is the route used when there is no other route for that destination. It is the route of last resort and is useful when a lot of traffic flows toward one upstream router or network (e.g., a home or business connection to an ISP).

Routers may also look at labels in a packet and use that information for routing. Multiprotocol label switching (MPLS), discussed later in this book, uses this mechanism.

Routing is converging with switching, and at times it is confusing to understand the differences between the two. A comparison of routing and switching is presented in Chapter 11.

Addressing and routing are used together to form an overall picture of connectivity for the network. An example of this is the local/remote decision to determine where to initially send packets. In the local/remote decision, a device (such as a user's computer) needs to decide whether the destination of a packet is local (on the same network) or remote. The destination IP address and mask (discussed earlier) are used to determine the network portion of the destination address. This is compared with the network portion of the sending device's IP address. If they are the same, the destination is on the same network (i.e., local). If the network portions of the IP addresses are different, they are on different networks (i.e., remote).

Why is this important? Part of the fundamental behavior of IP is in this local/ remote decision (Figure 6.5). IP requires that, if the destination address is local, then there is a lower-layer mechanism to directly transport that packet. As part of this requirement, every device on an IP network (or subnet, as we shall see later) must be able to directly communicate with every other device on that network. This means that the underlying network must have a mechanism to allow every device to communicate with every other device. This has implications on how address resolution at the lower layers is done, as we shall see later in this book.

Click To expand
Figure 6.5: Basic tenets of IP forwarding.

IP also requires that if the destination address is remote, then there is a router that can forward that packet toward its destination. Thus, a device on the network will need to know about which router or routers it can forward packets to. This can be learned by the device, through listening to routing protocol updates, or can be configured in the device. This router is termed the next-hop router for that network. In Figure 6.5, devices on the same subnet, 129.99.0.0, must be directly connected at the MAC/PHY layers. Devices are on the same subnet when they have the same network address, determined by applying the network mask to their addresses. Also in Figure 6.5, devices 129.99.0.1 and 129.99.0.2 are on the same network, as the network mask (/16 or 255.255.0.0) applied to each address resolves a network of 129.99.0.0. IP assumes this connectivity and passes IP datagrams down to the MAC and PHY layers for transport.

When devices are on different networks, there must be a router that can forward traffic between these networks. In the example in Figure 6.5, traffic between 129.99.0.0 and 136.178.0.0 passes through the adjoining router, which has interfaces on both networks.


6.4 Addressing Mechanisms

In this section we will discuss some of the popular mechanisms for addressing networks: classful addressing, subnetting, variable-length subnetting, supernetting and classless interdomain routing (CIDR), private addressing and network address translation (NAT), and dynamic addressing. Although these mechanisms all basically share the same theme (manipulating address space), we will treat them separately to highlight their differences.

Although the concept of classful addressing is a bit outdated, we will discuss it here to give some background on newer mechanisms and to provide insight on the addressing process.

6.4.1 Classful Addressing

Classful addressing is applying predetermined mask lengths to addresses to support a range of network sizes. The result is a set of classes of addresses (A, B, C, D, and E), each of which supports a different maximum network size. A class identifier at the beginning (first octet) of the address determines its class. A Class A address is indicated when the first bit of the first octet is 0 (network addresses 1 through 127), a Class B address is when the first bit is 1 and the second bit is 0 (network addresses 128 through 191), and a Class C address is when the first bit is 1, the second bit is 1, and the third bit is 0 (network addresses 192 through 223). The structures of classes A, B, and C are shown in Figure 6.6. Classes D and E are not shown here; they are used only for special purposes (Class D is used for multicast) or are reserved.

Click To expand
Figure 6.6: Classful addressing uses traditional class boundaries to form Class A, B, or C addresses.

Classful addresses default to a natural mask, which coincides with the class boundary and reflects that class's network and host space allocations. The natural mask is different for each class. For Class A addresses, the natural mask is 255.0.0.0, indicating that the bits in the first octet represent the network for that class. Since the first bit of the first octet is used to indicate a Class A address and neither all 0s nor all 1s can be used as network addresses (they represent broadcasts), there can be 27 - 2, or 126, possible networks. The device (host) portion of the mask is the remaining three octets, so there can be up to 224 2 or more than 16 million possible device addresses per network for Class A networks. So, Class A provides for a few very large networks.

The natural mask for Class B addresses is 255.255.0.0, so the first two octets represent the network for that class. Since the first two bits are used to identify the class, there can be 214 - 2, or 16,382, possible networks. The device portion of the mask is the remaining two octets, so there can be up to 216 - 2, or 65,534, possible device addresses per network. So, Class B provides for tens of thousands of (still quite large) networks. At one time this seemed like a lot of networks, but not anymore.

The natural mask for Class C addresses is 255.255.255.0, so the first three octets represent the network for that class. Since the first three bits are used to identify the class, there can be 221 - 2, or slightly more than 2 million, possible networks. The device portion of the mask is the remaining octet, so there can be up to 28 - 2, or 254, possible device addresses per network. So, Class C provides for millions of small networks.

There are two additional classes of address space (Classes D and E) that are used or reserved for special purposes. Class D is used for multicast addresses, and Class E is reserved. Class D address spaces are calculated the same way as the other classes, so Class D is indicated when the first, second, and third bits of the first octet are 1 and the fourth bit is 0 (network addresses 224 through 239).

Classful addressing was the first step to add hierarchy to addressing. Although the three classes can address from very small to very large networks, there are some fundamental problems with this scheme. First, Class A and B networks can address large numbers of devices. As it turns out, networks do not scale well to the size of a Class A or B, so further hierarchy is needed. Furthermore, as Class A and B address space ran out, the use of Class C address space had an impact on routing in the Internet. Clearly, something more than classful addressing was needed.

Example 6.2: Determining Class and Natural Mask
Start example

For the network address from Example 6.1, 136.178.10.1, determine its class and natural mask. Recall from Example 6.1, the binary representation of 136.178.10.1:

Click To expand

Looking at the first three bits (from left to right) of the first octet, we see that they are 100. Since the first bit must be 0 for a Class A address, 136.178.10.1 is not Class A. The first two bits are 10, which are consistent with Class B; therefore, 136.178.10.1 is a Class B address. The natural mask for this address is the natural mask for Class B, 255.255.0.0.

End example

There are limitations in allocating addresses based on Class A, B, and C boundaries. First, since there are relatively few Class A and B addresses, they have already been allocated. This leaves new networks with only Class C address space. Thus, a network may require many Class C addresses. Second, these class boundaries are not an efficient use of network addresses. Many networks require more addresses than a single Class C can provide yet are not large enough to justify a Class A or B, even if such network addresses were available. There are networks that have Class A or B addresses but can use only a small fraction of the total address space. What was needed was a more flexible method to match address space to the requirements of each network. This was accomplished by expanding the network mask to create subnets and variable-length subnets, as described next.

6.4.2 Subnetting

The next step in adding hierarchy to addressing is to allow a classful network address to be segmented into smaller sections. Subnetting (RFC 950) accomplishes this. Subnetting is using part of the device (host) address space to create another level of hierarchy. Changing the address mask increases the number of bits allocated to the network, creating the subnet. The resultant mask now includes a subnet mask, and the network segments that are created are termed subnets.

What is essentially being done in subnetting is that by changing the address mask to increase the number of bits allocated to the network, and thereby decreasing the number of bits allocated to devices, subnetting takes address space away from devices and gives it to the network.

Subnetting can be done on Class A, B, or C networks, although it is rare to subnet a Class C network (since there are only 254 addresses for devices anyway). The result of subnetting is a set of equal-sized subnets, where the length of the subnet mask determines the number of subnets and the size of each subnet. An example of this for Class B networks is shown in Figure 6.7.

Click To expand
Figure 6.7: Masks and sizes for subnetting a Class B network.

Subnetting is done to add hierarchy to a network. A network in which all devices are addressed with the same network address can have problems scaling to a large number of devices. The term large is relative; although some networks can have problems with a few dozen devices, others can scale to hundreds of devices without problems. The problems are usually related to traffic loads and behavior at the link and physical layers. The behaviors of users, applications, and devices will be reflected in the traffic flows on the network, and the characteristics of these flows (including their sources and sinks) will have an impact on the scalability of the network. How network devices are configured at the link layer will affect how they communicate at that layer. Problems at the link layer, such as jabbering devices or broadcast/multicast storms, will affect scalability of the network. Subnetting helps reduce the problem by segmenting the network into subnets connected by routers. Routers terminate the link and physical layers, thus stopping problems in one subnet from affecting other subnets.

Subnet masks (and therefore subnets) are recognized only within that network. When routes to that network are advertised, the natural mask is used. This is desirable because subnetting is used to provide hierarchy within that network, so there is no need to reveal that hierarchy outside of the network.

Example 6.3: Creating Subnets
Start example

Subnet 129.99.0.0 into seven subnets. 129.99.0.0 is a Class B (how do we know this?) address with a natural mask of 255.255.0.0. To create subnets, we increase the mask into the third octet by enough bits to get seven subnets. From the previous figure (see Figure 6.7), we see that three bits will give us seven subnets, using an extended mask (subnet mask) of 255.255.224.0, as shown here.

Click To expand

Each subnet is shown here in binary and dotted-decimal forms.

Subnet 1: | 10000001 | 01100011 | 00100000 | 00000000 | 129.99.32.0 | 255.255.224.0
Subnet 2: | 10000001 | 01100011 | 01000000 | 00000000 | 129.99.64.0 | 255.255.224.0
Subnet 3: | 10000001 | 01100011 | 01100000 | 00000000 | 129.99.96.0 | 255.255.224.0
Subnet 4: | 10000001 | 01100011 | 10000000 | 00000000 | 129.99.128.0 | 255.255.224.0
Subnet 5: | 10000001 | 01100011 | 10100000 | 00000000 | 129.99.160.0 | 255.255.224.0
Subnet 6: | 10000001 | 01100011 | 11000000 | 00000000 | 129.99.192.0 | 255.255.224.0
Subnet 7: | 10000001 | 01100011 | 11100000 | 00000000 | 129.99.224.0 | 255.255.224.0
End example

6.4.3 Variable-Length Subnetting

Subnetting segments a network into a number of equal-sized subnets, which is often inefficient. If a goal of subnetting is to create subnets that are scaled to the sizes of groups (workgroups) in the organization so that a subnet can be allocated to each group, then it is desirable to have subnets of different sizes. Variable-length subnetting is subnetting in which multiple variable-length subnet masks are used, creating subnets of different sizes.

This practice allows for a better mapping of subnets to workgroups. For example, the following organization has a number of workgroups of varying sizes.

Workgroup | Groups | Size/Group (Devices)
Engineering | 3 | 400 (1200 total)
Marketing | 1 | 1950
Administration | 1 | 200
Sales | 15 | 35–90 (1350 total)
Research and development (R&D) | 1 | 150
Support | 22 | 10–40 (880 total)
Total | 43 | 5730

This organization has a Class B address (136.178.0.0, mask 255.255.0.0) and would like to give one subnet to each group. If we were to just use the natural mask, this network would support 65,534 devices, which is far more than needed. However, it is likely that the network would have problems scaling to that size. We cannot implement subnets of equal size, given the requirement of one subnet per group. To support the largest group (Marketing, with 1950 devices), we would need a 5-bit or smaller subnet mask. But this would give a maximum of 31 possible subnets (with a 5-bit mask). To have enough subnets, we would need a 6-bit or larger subnet mask, but then the size of the subnet would not be large enough for Marketing. By using variable-length subnetting, we can tailor the subnets to the sizes of the groups and how many subnets we need.

For this example we choose to use a combination of 4-bit and 8-bit subnet masks. With a 4-bit mask (255.255.240.0), we would have 15 subnets, each with a maximum of 4096 devices. This would be sufficient for Engineering and Marketing. The 8-bit subnet mask (255.255.255.0) provides subnets that can have a maximum of 254 devices each, sufficient for each of the groups is Sales, R&D, and Support.

The subnet allocations are as follows: The 4-bit mask (255.255.240.0) is used to allocate the following 15 subnets:

136.178.16.0 | 136.178.96.0 | 136.178.176.0
136.178.32.0 | 136.178.112.0 | 136.178.192.0
136.178.48.0 | 136.178.128.0 | 136.178.208.0
136.178.64.0 | 136.178.144.0 | 136.178.224.0
136.178.80.0 | 136.178.160.0 | 136.178.240.0

Not all of these subnets would be used at this time. We would allocate three subnets to Marketing (136.178.16.0, 136.178.32.0, and 136.178.48.0), one subnet to Marketing (136.178.64.0), and we probably should allocate one to Administration (136.178.80.0), as it would be close to the maximum number of devices for an 8-bit subnet.

For the 8-bit mask, we would take one of the 4-bit subnets and apply the 8-bit mask to it. We could take the next 4-bit subnet available (136.178.96.0) and apply an 8-bit mask (255.255.255.0), yielding the following 8-bit subnets:

136.178.97.0 | 136.178.102.0 | 136.178.107.0
136.178.98.0 | 136.178.103.0 | 136.178.108.0
136.178.99.0 | 136.178.104.0 | 136.178.109.0
136.178.100.0 | 136.178.105.0 | 136.178.110.0
136.178.101.0 | 136.178.106.0 | 136.178.111.0

These are all the 8-bit subnets between 136.178.96.0 and 136.178.112.0. Each of these subnets can support up to 254 devices. We would allocate 15 of these subnets (136.178.97.0 through 136.178.110.0) to Sales and the last one (136.178.111.0) to R&D. At this point we need to create more 8-bit subnets (22 subnets for Support), so we would repeat this procedure for the next two available 4-bit subnets (136.178.112.0 and 136.178.128.0). For 136.178.112.0:

136.178.113.0 | 136.178.118.0 | 136.178.123.0
136.178.114.0 | 136.178.119.0 | 136.178.124.0
136.178.115.0 | 136.178.120.0 | 136.178.125.0
136.178.116.0 | 136.178.121.0 | 136.178.126.0
136.178.117.0 | 136.178.122.0 | 136.178.127.0

and for 136.178.128.0:

136.178.129.0 | 136.178.134.0 | 136.178.139.0
136.178.130.0 | 136.178.129.0 | 136.178.140.0
136.178.131.0 | 136.178.136.0 | 136.178.141.0
136.178.132.0 | 136.178.137.0 | 136.178.142.0
136.178.133.0 | 136.178.138.0 | 136.178.143.0

The 22 subnets for Support would be (136.178.113.0 through 136.178.127.0, and 136.178.129.0 through 136.178.129.0). The remaining 4-bit and 8-bit subnets would be available for future growth.

6.4.4 Supernetting

As mentioned earlier, there are not many Class A and B networks (on the order of tens of thousands). As these network were allocated, it became necessary to allocate several Class C network addresses in place of a single Class A or B. Recall that there are millions of Class C networks that can be allocated.

What happens when Class C addresses are used in lieu of Class A or B addresses? Consider, for example, addressing strategy for a company with 10,000 devices. A single Class B could support up to 65,534 devices, which would be plenty for this company, but a Class B is not available, so Class C addresses are used instead. A single Class C can support up to 254 devices, so 40 Class C networks are needed (40 networks × 254 addresses/network 10,160 total addresses).

When 40 Class C networks are allocated to this company (e.g., 192.92.240.0 through 192.92.279.0), routes to each network will have to be advertised to the Internet. Thus, instead of an advertisement for a single Class B network for this company, we now have advertisements for 40 Class C networks. Each route advertisement would be added to the routers in the Internet, using memory and processing resources. As you may imagine, the number of routes would grow exponentially, as would the memory and processing requirements in the routers. In fact, this was a problem in the Internet in the 1990s. There were predictions that the Internet would collapse in 1995, yet this did not happen. Through the ingenuity of Internet engineers at that time, a mechanism was found to alleviate this problem. The answer is supernetting.

Supernetting is aggregating network addresses by changing the address mask to decrease the number of bits recognized as the network. By decreasing the number of bits recognized as the network, we are in effect ignoring part of the network address, which results in aggregating network addresses.

Let's see how this works. We will consider a block of 16 contiguous Class C addresses (you will shortly see why 16 was chosen, and why it is contiguous), 192.92.240.0 through 192.92.255.0, with their natural mask 255.255.255.0:

192.92.240.0 | 192.92.248.0
192.92.241.0 | 192.92.249.0
192.92.242.0 | 192.92.250.0
192.92.243.0 | 192.92.251.0
192.92.244.0 | 192.92.252.0
192.92.245.0 | 192.92.253.0
192.92.246.0 | 192.92.254.0
192.92.247.0 | 192.92.255.0

You will notice that the first, second, and last octets of this group of addresses do not change. They are 192, 92, and 0, respectively. The third octet does change for each address. If we look at the binary representation of this octet for these addresses, we get Figure 6.8:

Click To expand
Figure 6.8: Modifying the address mask for supernetting.

Notice that the first four bits in this octet do not change, only the last four bits do. Also notice that the last four bits are represented in their full range of values, from (binary) 0000 to 1111. Therefore, if we choose to ignore the last four bits in this octet, we get a single address that represents the full range of 16 addresses. That address is 192.92.240.0 (the first address of the group), and its mask is 255.255.240.0 (the natural mask minus the last four bits). This mask is termed the supernet mask.

How does that work? Let's first look at 192.92.240.0 with its natural mask, 255.255.255.0. These addresses are shown in Figure 6.9 as decimal and binary representations.

Click To expand
Figure 6.9: IP address shown with natural mask.

When the natural mask is applied to the address, we get a single Class C network with 254 device addresses. If we look at this network with the new supernet mask, we get Figure 6.10:

Click To expand
Figure 6.10: IP address shown with supernet mask.

The difference here is that, with the new supernet mask, the last four bits of the third octet are not recognized as part of the network, so they can be anything (0000 to 1111). As a result, we get a set of 16 addresses, ranging from 192.92.240.0 (where the last four bits of the third octet are 0000) to 192.92.255.0 (where the last four bits of the third octet are 1111). Thus, the single advertisement of 192.92.240.0 with supernet mask 255.255.240.0 is the equivalent of 16 advertisements for addresses 192.92.240.0 through 192.92.255.0.

Supernetting reduced the number of advertisements in the Internet and changed the way most people view addressing. If we can change the mask length to aggregate networks, why do we need class boundaries at all? The answer is that we don't. The term classless interdomain routing (CIDR) is used to denote the absence of class boundaries in network routing. The dotted-decimal notation for masks can be replaced by noting the length of the mask in bits. For example, the supernet mask 255.255.240.0 shown previously would be described as a 20-bit mask, and the combination of address and mask would be 192.92.240.0/20. The block of networks that are addressed in this way is termed a CIDR block. According to this convention, a single Class C network would have a mask length of 24 bits (/24), and a single Class B network would have a mask length of 16 bits (/16). When a mask is shown as a length in bits, it is called an address prefix.

By describing networks this way, we are really creating arbitrary hierarchies in the network. By changing the mask length, we can change the degree of aggregation of networks. This is now common practice in the Internet community.

There are some conventions that are followed in supernetting: The number of addresses in a CIDR block are powers of two, and the block of addresses is contiguous—that is, there are no holes in this address space.

The number of addresses in a CIDR block is a power of 2, based on the number of bits that are not recognized by the mask. If we look at 192.92.240.0 with a /24 (the natural mask), we get one network—192.92.240.0. With a /23 mask, we ignore the last bit of the third octet, and we get two networks—192.92.240.0 and 192.92.240.1. As you can see in Figure 6.11, this can continue for /22, /21, and so on. Each time we increase the number of possible networks by a factor of two.

Click To expand
Figure 6.11: Address prefix size determines CIDR block size.

When the address space is not contiguous (i.e., there are one or more network addresses missing from the CIDR block), there is the potential for problems. In our discussion on supernetting, it should be clear that, in the process of changing the mask length, we are ignoring some of the bits in the address. The bits that are ignored can take on any value, and the result is that a range of networks is assumed. If one or more of the networks in that range is not part of the CIDR block (e.g., that network address is being used by somebody else), it will still be advertised as part of the range of addresses in that block.

For example, the advertisement 200.1.128.0/17 is equivalent to a range of 27, or 128, networks, from 200.1.128.0 to 200.1.255.0. If one of these addresses, say, 200.1.200.0/24, was already allocated to another customer, it will still be included in the advertisement 200.1.128.0/17. Does this mean that advertisements cannot have any such "holes" in them? Fortunately, this will still work. As was discussed at the beginning of this chapter, routers will choose the best match for a destination. Given a number of routes (in the router's forwarding table) that would work, the router will choose the one that is the longest match to the destination address of the packet. If the single network 200.1.200.0/24, which is in the CIDR block advertisement 200.1.128.0/17, is owned by somebody else, packets with a destination address of 200.1.200.0/24 would be forwarded to the 200.1.200.0 network, as it is a better (longer) match than 200.1.128.0/17.

6.4.5 Private Addressing and NAT

Private IP addresses are those that cannot be advertised and forwarded by network devices in the public domain. This was originally done to help with address space depletion in the Internet, for if networks that would normally be allocated public address space instead use private address space, those public addresses would remain available.

The Internet Engineering Task Force has defined in RFC 1918 three blocks of private address space:

  • 10.0.0.0 through 10.255.255.255 (10/8 prefix)

  • 172.16.0.0 through 172.31.255.255 (172.16/12 prefix)

  • 192.168.0.0 through 192.168.255.255 (192.168/16 prefix)

There is a side benefit from using private addresses. It turns out that since these addresses are not advertised and forwarded in the Internet, this can provide a degree of security for that network. What is needed in order for this to work, however, is a mechanism to translate addresses from the private address space to the public address space. NAT is such a mechanism. NAT maps IP addresses between public and private spaces.

In translating between public and private address spaces, NAT creates bindings between addresses. These can be one-to-one address bindings (known as static NAT), one-to-many address bindings (known as dynamic NAT), and address and port bindings (known as network address port translation [NAPT]).

Often combinations of static, dynamic and NAPT bindings are used in a network. For example, dynamic NAT is often used for user devices, and static NAT is often used for servers.


6.5 Routing Mechanisms

The routing mechanisms we will consider here are establishing routing flows, identifying and classifying routing boundaries, and manipulating routing flows.

6.5.1 Establishing Routing Flows

In preparation to discuss boundaries and route manipulation, we want to understand how flows will likely be routed through the network. As we will see in this chapter, addressing and routing are both closely coupled to the flow of routing information in the network, and the addressing and routing architecture is based partially on establishing these flows.

Determining routing flows begins with the flow analysis process. When you develop flows in the flow specification and flow map, they form the foundation for routing flows, as traffic flows are what are routed through the network.

The process of establishing routing flows in the network consists of segmenting the network into functional areas and workgroups, identifying boundaries between these areas, and then forming the relationships between boundaries and routing flows.

Functional areas (FA) are groups within the system that share a similar function. Groups may be of users (workgroups), applications, devices, or combinations of these, and they may share similar jobs/tasks, physical locations, or functions within the network (e.g., backbone routing). Workgroups (WG) are groups of users that have common locations, applications, and requirements, or that belong to the same organization.

The purpose of FAs is to simplify the routing architecture. They can cross physical boundaries, such as rooms, floors, and buildings. A WG is similar to an FA but is one level lower in hierarchy.

Consider Figure 6.12. In this figure, there are multiple WGs, in this case based on organizations within a company. FAs are created: the Scientists and Accounting groups in Building C, the two Management WGs in Building B, the Scientists groups across Buildings A and C, and the backbone between the buildings. Notice that FAs are connected with routers.

Click To expand
Figure 6.12: Example of workgroups and functional areas.

6.5.2 Identifying and Classifying Routing Boundaries

Routing boundaries are physical or logical separations of a network, based on requirements for or administration of that network.

Physical boundaries can be identified by isolation LANs or demilitarized zones (DMZs), physical interfaces on network equipment, or physical security. Logical boundaries can be identified by FAs, WGs, administrative domains, such as autonomous systems (AS), and routing management domains.

Autonomous systems have AS numbers associated with them. Routing management domains are often the same as ASs but can be either a subset or a superset of one or more ASs. Security domains are places where security devices are located and may use public address space outside the security boundary and private address space inside.

The type of routing protocol used to pass routing information across the boundary may also distinguish boundaries. Two general types of routing protocols exist. Exterior Gateway Protocols (EGPs) communicate routing information (reachability and metrics) primarily between ASs. Interior Gateway Protocols (IGPs) communicate routing information primarily within an AS. The word primarily is used here, for EGPs can be used within an AS and IGPs can be used between ASs, although this is rarely done. Later in this chapter we will look at ways to combine EGP and IGP use both within and between ASs.

Here, we use the term hard boundary to describe a routing boundary in which EGPs are predominantly used to pass routing information, whereas a soft boundary is a routing boundary in which IGPs are predominantly used. Hard boundaries are found between ASs, between an AS and an external network (which may or may not have an AS associated with it) or at well-defined separations between networks within an AS (e.g., at interfaces between internal organizations within a company in which different administrative domains exist). Hard boundaries are also found at interfaces to ISPs and are associated with DMZs. Figure 6.13 shows an example of a hard boundary.

Click To expand
Figure 6.13: Example of a hard boundary.

In this example, a network is used to separate an enterprise AS from an ISP. A network that is used to separate other networks (provide a buffer between them) is often termed an isolation LAN (iLAN). Another term for iLAN is DMZ. DMZ denotes a buffer area between two factions—in this case, the two networks being separated. This is a common hard boundary and is one in which an EGP is likely to be used. Another example is when an enterprise wants to restrict communications between certain organizations within that enterprise (e.g., to/from the Accounting WG). Although the entire organization is within an AS, the boundary between the Accounting WG and the rest of the AS is similar to a DMZ (it could be considered an internal DMZ), so this is also a hard boundary. An EGP or IGP may be used in this case.

Soft boundaries are typically found within a single AS and are usually placed at the junction of FAs or WGs, as in Figure 6.14. In this figure, all of the interfaces between FAs are soft boundaries.

Click To expand
Figure 6.14: Example of a soft boundary.

Why are we interested in determining routing boundaries for our network? Routing boundaries are important because they are the focal points for routing flows. Recall from our examples that between FAs and between ASs, hard and soft boundaries are located at routers, which aggregate routing traffic. These are also locations where hierarchies are established in the network. Figure 6.15 shows boundaries and routing flows for a network.

Click To expand
Figure 6.15: Boundaries and routing flows in a network.

Routing flows are flows of routing information, passed between FAs, as well as between ASs. This routing information includes routing initialization, updates, transients, and background traffic such as "hello" or "keepalive" messages. Routing boundaries and flows are important to the development of the architecture and design, for routing flows can be manipulated at routing boundaries.

6.5.3 Manipulating Routing Flows

Manipulating (i.e., controlling) routing flows within the network is vital to the proper operation and performance of the network. The right combination of addressing and routing is important in this process to localize routing flows whenever possible.

Several techniques can be used to manipulate routing flows at hard and soft boundaries. We can supply a default route through our network via default route propagation. We can use route filtering to hide routes, and route aggregation to simplify advertisements. We can develop peering relationships between networks or ASs across boundaries. We can also develop routing policies and policy enforcement.

A default route is the route used when there is no other route for that destination. Usually, this is the route with the highest available capacity to external networks. Default route propagation is the technique used to inform the network (or subnets or FAs) of the default path; propagation begins at the exit point for the network.

Route filtering is the technique of applying route filters to hide networks from the rest of an AS, or to add, delete, or modify routes in the routing table. A route filter is a statement, configured in one or more routers, that identifies one or more IP parameters (e.g., an IP source or destination address) and an action (e.g., drop or forward) to be taken when traffic matches these parameters. Route filtering is commonly used at hard boundaries. When the IGP OSPF is used, route filtering should not be used to hide networks internal to the OSPF network. This is due to the nature of the route-calculation algorithm in OSPF, which will be discussed later in this chapter.

Route aggregation is the technique of exchanging routing information between ASs, usually between service providers with transit networks and between large customer networks. This technique is typically used at hard boundaries and may include policy information. Historically, on the Internet, peering was the free and open exchange of routes between large transit networks, but changes in the structure and operation of the Internet have modified peering arrangements, so now they are somewhat competitive.

Policies are higher-level abstractions of the route filtering technique described earlier. Just as a route filter takes an action (e.g., drop, accept, modify) on traffic that matches one or more parameters (e.g., IP addresses), a policy takes a similar action on traffic that matches one or more AS parameters (e.g., AS number or list of AS numbers and metrics, time of day, cost).

Policies allow an AS to accept or deny traffic, or to modify routing information passed between ASs, based on high-level parameters. This allows decisions about routing traffic to be made on a basis other than route metrics. Policies are typically applied across hard boundaries and are currently used with the EGP BGPv4, discussed later in this chapter.

For example, consider a group of interconnected ASs, as in Figure 6.16. Router 1 peers with Routers 2 and 3. Routers 2 and 3 enforce a policy that traffic from AS1 must transit AS2 in order to get to AS4, and this traffic cannot transit AS3.

Click To expand
Figure 6.16: Policy enforcement between autonomous systems.

To illustrate these route-manipulation techniques, we will discuss each as applied to the example in Figure 6.17.

Click To expand
Figure 6.17: Example for route-manipulation techniques.

The routing requirements for AS1 are as follows:

1.1. | Provide primary Internet access for AS1 is through ISPa.
1.2. | Provide redundant (secondary) Internet access for AS1 is through ISPb.
1.3. | Allow AS2 traffic to transit (go through) AS1 to get redundant Internet access via ISPa.
1.4. | Only allow communication between WGa1 in AS1 and WGc1 in AS2 via link L7.

Requirements 1.1 and 1.2 are solved by establishing peering agreements with both ISPa and ISPb. This agreement specifies that ISPa should propagate a default route to AS1 with a lower routing cost than the default route from ISPb to AS1. Also, within this peering agreement, AS1 will advertise an aggregate route for its subnets to ISPa with a lower cost than to ISPb. Peering is done across a hard boundary, so it is typically accomplished with an EGP (e.g., BGP4).

For requirement 1.3, a third peering agreement is developed between AS1 and AS2 via links L1 and L2. AS1 accepts aggregate routes from AS2 and passes them through AS1 to ISPa at a higher cost than the cost AS2 uses to ISPb. The earlier peering agreement is modified to allow AS1 to send AS2's routes to it. ISPa agrees to propagate AS2's routes to Internet at higher cost than ISPb.

For requirement 1.4, a fourth peering agreement is established between AS1 and AS2 via link L7. AS1 accepts route advertisements from AS2/WGc1 for subnets within this WG via link L7. Route filtering is applied to block any other traffic.

The results of applying route-manipulation techniques to the routing requirements of AS1 are shown in Figure 6.18.

Click To expand
Figure 6.18: Results of route-manipulation techniques applied to AS1.

The routing requirements for AS2 are as follows:

2.1. | WGc5 can communicate with WGc4 only via link L8.
2.2. | Only allow traffic from AS1 that is received over link L7 destined for WGc1 to pass; block all other traffic.
2.3. | Allow FAc3 to use FAc4 as an alternative path to the Internet via link L6.
2.4. | Do not allow FAc2 to use FAc3 as an alternative path to Internet via link L8.
2.5. | Do not advertise WGc2.
2.6. | WGc1 can communicate with AS1/WGa1 via only link L7; deny all other traffic.
2.7 | All other FAs must use FAc1 as the default path.
2.8. | Use AS1 as a transient AS for redundant access to the Internet via ISPa.
2.9. | Use ISPb as primary access to Internet.

Requirement 2.1 is solved by applying route filtering at both WGc5 and WGc4 to force this routing to take place and to prevent other WGs from using link L8. For 2.2, a peering agreement with AS1 is established, and route filtering is applied at link L7. Requirement 2.3 is solved by having FAc4 propagate a default route via link L6 to FAc3 with a higher cost than FAc3 is getting from FAc1. In 2.4, route filtering is applied to FAc2 and FAc3, as was done in problem 2.1.

For requirement 2.5, route filters are applied at routers that connect to WGc2 to keep that WG from being advertised. In requirement 2.6, route filtering is used again, this time to force communications via link L7. Be careful to not allow WGc1 to use link L7 as access to the Internet. In 2.7, FAc1 propagates the default route to all FAs. All FAs will aggregate route advertisements at the soft boundaries.

For requirement 2.8, another peering agreement (agreement number 5) is established with AS1 to allow AS2 to use AS1 as a transit AS to access ISPa in the event that ISPb fails. AS2 must advertise aggregate routes to AS1 with a higher cost than it is sending to ISPb.

In requirement 2.9, a peering agreement is established between ISPb and AS2. AS2 will advertise aggregate routes to ISPb, ISPb will advertise default to AS2, and ISPb will propagate AS2's routes to the Internet.

The results of applying route-manipulation techniques to the routing requirements of AS2 are shown in Figure 6.19.

Click To expand
Figure 6.19: Results of route-manipulation techniques applied to AS2.


6.6 Addressing Strategies

During the requirements analysis process, you must gather information about device growth expectations so that you can avoid having to change addressing schemes and reconfiguring device addresses during the life cycle of the network.

When applying subnetting, variable-length subnetting, classful addressing, supernetting, private addressing and NAT, and dynamic addressing, we want to make sure that our network addresses and masks will scale to the sizes of the areas to which they will be assigned. We also want to establish the degrees of hierarchy in the network. To scale the network addressing, we will use the numbers of:

  • FAs within the network

  • WGs within each FA

  • Subnets within each WG

  • All the subnets (current and future) in the organization

  • All the devices (current and future) within each subnet

By establishing the scaling and hierarchies for our network, we are applying addressing, not only system-wide but also across FAs, WGs, and subnets. The intent here is to look at addressing from many perspectives so that we do not lose the detail of any particular area and do not fail to see the overall addressing picture. While each of the addressing strategies could be applied to any area of the network, there are areas where each strategy is more appropriate. Figure 6.20 shows where each strategy applies.

Click To expand
Figure 6.20: Applying various addressing strategies.

At the bottom of the hierarchy, where devices and subnets are addressed, variable-length subnetting can provide the flexibility needed to map addresses to various network/device sizes. In the middle of the hierarchy, where there are FAs and WGs, subnetting is often sufficient. At the top end of the hierarchy, where the entire network resides (as well as most external interfaces), using the natural mask for the network address or applying subnetting is usually appropriate. The hierarchies of variable-length subnetting, both internal and external to the network, are shown in Figure 6.21.

Click To expand
Figure 6.21: Example for variable-length subnetting.

In Figure 6.21, a hub router connects a number of WG routers to an ISP. This hub router can interconnect up to 10 networks but is currently connected to 5 networks. Each WG router should be configured to support four networks, with each network having 10 to 20 devices attached to it. We have been assigned the CIDR block 192.92.240.0/20, which we are expected to summarize to the ISP router.

We can break this network into addressing areas, based on the numbers of FAs, WG, networks, and devices. This will help us choose address mask sizes that are appropriate for the scale of our network.

In this example there are three distinct areas to address. First, the WGs have four networks, with 10 to 20 devices per network. For this area, we could assign from the CIDR block a Class C per WG, subnetted with a mask of 255.255.255.224 (or /27), which will support up to six subnets with up to 30 devices per subnet. The next area is where the WG routers connect to the hub router. If addresses need to be assigned (if the routers do not support unnumbered links), we could subnet a single Class C from the CIDR block with a mask of 255.255.255.252 (or /30), supporting 63 subnets with two devices per subnet.

These connections are point-to-point between each WG router and the hub router, so we will need to address only two devices per connection. The third area is the connection between the hub router and the ISP router. Here, we will provide the summary advertisement 192.92.240.0/20. The result is shown in Figure 6.22.

Click To expand
Figure 6.22: Example with variable-length subnetting applied.


6.7 Routing Strategies

This section introduces and describes popular interior and exterior routing protocols. Section 6.7.1 describes which protocols are best for which circumstances, and Section 6.7.2 describes how to select the appropriate ones to use within each network.

Now that we have the framework for routing developed and some addressing strategies, let's consider some strategies for applying routing protocols. This section covers the characteristics of some popular routing protocols, criteria for making selections from these protocols, and where to apply and mix these protocols.

Typically, when routing protocols are evaluated, it is on the basis of characteristics that are somewhat distant from the overall architecture, such as their convergence times; their protocol overheads, in terms of capacity (bandwidth overhead), CPU utilization, and memory utilization; and their stability. Although these are important characteristics to consider, it is often difficult to relate them directly to the network architecture or design. They are, however, indirectly related to the architecture and design through two characteristics discussed several times in this book: hierarchy and interconnectivity.

From the perspective of choosing a routing protocol, the hierarchy and interconnectivity of the network helps determine the required complexity and features of the routing protocol. In determining the degrees of hierarchy and interconnectivity in the network, we are indirectly applying the two aforementioned characteristics to the network.

For example, convergence time for a routing protocol is directly related to the degree of interconnectivity in the network. When used to provide redundancy, a higher degree of interconnectivity implies a requirement for predictable or guaranteed (mission-critical) reliability. This may also be explicitly stated as a requirement from the requirements analysis. As interconnectivity increases in importance, the routing protocol will need to converge rapidly when changes in the routing topology occur. This also indicates a need for stability in the routed network.

In distributed networks (which routed networks usually are), hierarchy tends to force decision making (e.g., routing decisions) down the tree. In the case of routing protocols, this may require an abstraction of hierarchy in the routing protocol itself, such as the area abstraction in OSPF.

We can apply degrees of hierarchy and interconnectivity to our evaluation of routing protocols. In addition, in evaluating the routing protocols for your network, you will want to ensure that the network is segmented into FAs and WGs.

Other criteria to consider in routing protocols are the relative complexities of the protocols, or their ease of use, and the interoperability of the protocol. These criteria may be dependent on how the vendor implements the routing protocol, making them more difficult to assess subjectively. Some of the many trade-offs in routing protocol choices are simplicity and ease of use versus sophistication and features, and interoperability versus vendor-specific features.

Some routing protocols are relatively simple to configure and maintain. RIP, for example, is pretty much a "plug-and-play" routing protocol, as long as the network is not too large and you do not try anything complex. Easy-to-use protocols tend to not have many features or options and may not scale well to high degrees of hierarchy or interconnectivity. As routing protocols increase in features or scalability, they also become more complex, requiring greater expertise on the part of the staff that will be operating the network. The routing protocol may have some parameters that are tunable, allowing network operators to change the values of these parameters to optimize protocol performance or features. This can be a great help for networks that have extreme size, unique topology characteristics, or multitier performance requirements, but it also requires quite a bit of personnel resources in monitoring and maintenance.

Interoperability is support for operations, administration, maintenance, and provisioning (OAM&P), performance and features across multiple vendor platforms. For routing protocols, standards are the start toward interoperability. Standards are necessary, but not sufficient, for protocol interoperability. Do not assume that, when an implementation of a routing protocol supports or is based on a standard, it will interoperate with all other vendor implementations of the same protocol. To be certain of interoperability, you need to know which vendor implementations you expect to deploy in the network and then either check to see what interoperability tests have been done (there are several test labs that perform such tests and release information to the public) or test interoperability yourself, in your own test environment.

At times, it may be necessary to accept reduced interoperability to get features or performance from a particular vendor. For example, we may get a highly desirable feature with a vendor-specific routing protocol or a degree of support from the vendor that far exceeds that with a standard protocol. However, although there are times when vendor-specific routing protocols may be considered, they should always be considered with caution. If you choose a vendor-specific (proprietary), nonstandard routing protocol, you run the risk of becoming locked into using that protocol. It may prove expensive to include or change to a standard protocol later, as the network operations staff may have to learn this new protocol, including interactions with the existing protocol. Once locked into a proprietary routing protocol, you may be forced to continue to buy and deploy that vendor's equipment, even though this may not be optimal for your network.

6.7.1 Evaluating Routing Protocols

We will briefly examine and compare some popular IGPs and EGPs: RIP and RIPv2, OSPF, and BGPv4. We will also consider the limited use of static routes in the network. We will not consider any proprietary routing protocols in this book.

Static routes are routes that are configured manually, by network personnel or scripts, in network devices and that do not change until manually deleted or modified. As such, they are not routing protocols but are considered in this chapter since they have an impact on the routing in a network. Many people overlook the use of static routes, yet they can be useful in some networks, primarily when a routing protocol is not needed. Some disadvantages to static routes are that they require maintenance and they require resources on routers. This can become significant with a large number of static routes.

Routing protocols are dynamic. They learn about reachability within and between networks and update that information periodically; thus, they are needed when alternative paths exist in the network (i.e., there is some degree of interconnectivity). When there is only one path into or out of an area, a routing protocol cannot adapt to changes in topology. A stub network is a network with only one path into or out of it, as in Figure 6.23.

Click To expand
Figure 6.23: Stub networks.

With stub networks, a static route can be applied between the stub network and the network to which it is connected. A trade-off in using static routes is not having to configure and maintain a routing protocol versus having to maintain the static routes. Since a stub network has only one path into or out of it, a default route is usually all that is needed. A static route may be used to provide this default.

Static routes can also be used to force routing along a certain path. Since a routing protocol is not used, alternative paths are not learned or used, thus forcing traffic to use the static route. This can be useful (e.g., it is sometimes used to enhance security), but it should always be used with caution.

Whenever there are multiple paths into and out of a network, a routing protocol should be considered. Popular routing protocols, such as RIP, RIPv2, and OSPF, use either a distance-vector or a link-state routing algorithm to determine reachability.

In a distance-vector routing algorithm, each router maintains the "distance" (a metric to weight each hop, or connection, between routers) between itself and possible destinations. A vector (or list) of these distances is computed from distance information received from other participating routers on that network. In a link-state routing algorithm, each router learns about itself, its links to next-hop routers (its neighbors), and the state of each link. This information is multicasted to other participating routers, and all routers build their routing information from the sum of these multicasts.

For an excellent description of routing protocol algorithms, see Interconnections, second edition (listed in Section 6.2).

RIP and RIPv2 are IGPs that are based on a distance-vector routing algorithm. This implies some characteristics of the dynamic behavior of RIP/RIPv2-routed networks. RIP and to a lesser degree RIPv2 are relatively straightforward to implement and maintain. RIP has been around for a long time (more than 30 years), having been part of the TCP/IP suite shipped with most UNIX systems, and there is a lot of experience with RIP-routed networks. Given the simplicity, longevity, and experience with RIP, interoperability between various versions of RIP should not be a problem.

Because of the nature of the distance-vector routing algorithm used in RIP/RIPv2, they can be slow to converge to a new routing topology when changes occur in the network, where "slow" is on the order of minutes. They can also form routing instabilities in networks with high degrees of hierarchy or interconnectivity, although several mechanisms have been developed to minimize the probabilities of their forming (e.g., poison reverse, hold-down timers). For these reasons, they are not optimal for areas that have high degrees of hierarchy or interconnectivity.

RIP/RIPv2 should be considered when there is low to medium hierarchy and interconnectivity in the network. Degrees of hierarchy and interconnectivity are shown in Figure 6.24.

Click To expand
Figure 6.24: Degrees of hierarchy and interconnectivity.

OSPF is an IGP that is based on a link-state algorithm. Like RIP/RIPv2, the choice of routing algorithm affects the characteristics of the protocol. In the case of OSPF, the use of a link-state algorithm results in a faster convergence time when changes in the routing topology occur. Convergence times can be on the order of seconds, one to two orders of magnitude faster than RIP/RIPv2. For an area with high hierarchy or interconnectivity, a fast convergence time may be the single most important feature of a routing protocol and would indicate the use of OSPF.

OSPF also supports an area abstraction, which provides a hierarchy for routing information. The OSPF hierarchy connects these areas via a backbone area, and routing information is internalized within each area. This reduces the size of routing information flows across the OSPF network. In addition to the area abstraction, OSPF supports equal-cost multipath, allowing multiple paths to be used to the same destination when their OSPF costs are the same.

There are trade-offs for OSPF's rapid convergence times and area abstraction. One trade-off is in complexity. OSPF can require a substantial amount (relative to RIP) of configuration during setup and possibly configuration tuning to reach an optimized steady-state routing topology. There is more information to understand, monitor, and use in an OSPF-routed network. This information can be helpful in isolating and troubleshooting routing problems, but personnel skilled in using this information are also required. In addition, interoperability between various OSPF implementations is less certain than with RIP.

OSPF should be considered when there is high hierarchy and interconnectivity in the network (see Figure 6.24).

BGPv4 (or BGP) is a path-vector-based EGP. A path-vector algorithm is similar to a distance-vector algorithm, such as that used in RIP; however, it operates on ASs or lists of ASs (paths). In addition, BGP can use policies to determine actions to be taken on paths.

BGP exchanges routing information via establishing peering connections using TCP with a user-defined list. BGP is used to enforce network transport policies for an AS, such as allowing all routes from a certain AS to use this AS as a transit route, rejecting all routes that have been learned from a certain AS, and announcing only certain routes from this AS to other peers.

The configuration of BGP depends on the complexity of your policy definitions. Once these are configured, BGP will operate within those policies in a dynamic manner. BGP is best suited as an inter-AS (interdomain) routing protocol, although there are times when it is used within an AS.

BGP operates between ASs, yet there may be a number of routers (termed border routers) that connect to external networks. As such, there needs to be a mechanism for border routers from the same AS to communicate path information so that it can be passed to multiple ASs (Figure 6.25).

Click To expand
Figure 6.25: Application of internal BGP (iBGP) and external BGP (eBGP).

Therefore, there are two types of BGP: external BGP (eBGP) and internal BGP (iBGP). eBGP is the "normal" operational mode of BGP—passing path information between ASs. iBGP is used to form tunnels between border routers within an AS to pass path information across that AS. Why is this necessary? BGP communicates path information and policies, which are not (as yet) recognized by IGPs. Thus, if border routers within an AS were forced to use an IGP to communicate (e.g., OSPF), the path and policy information would be lost in translating between BGP and OSPF. Therefore, tunnels are used so border routers do not need to translate BGP to an IGP.

6.7.2 Choosing and Applying Routing Protocols

This section presents some recommendations for choosing and applying routing protocols for your network. They were developed to simplify the application of routing protocols whenever possible. These recommendations are as follows:

  1. Minimize the number of routing protocols used in the network. Two should be the maximum number of protocols allowed, with only one IGP.

  2. Start with the simplest routing strategy and routing mechanism/protocol.

  3. As the complexity in routing and choices of routing protocols increases, reevaluate the previous decisions.

Minimizing the number of routing protocols is straightforward: Do not overcomplicate the routing architecture by applying too many routing protocols. How many routing protocols is "too many" is based on the ability of the customer—specifically those responsible for OAM&P of the network—to support those protocols. It does not make sense to architect and design a complicated network that cannot be managed by the network staff. Many networks focus on a single IGP within their AS and an EGP for external communications. However, as we will see, there are times when multiple IGPs within and AS and even a mix of IGPs and EGP together within an AS can work, as long as the trade-offs in complexity and support are well understood.

We also want to start with the simplest routing strategy and work up to more complex strategies when necessary. The simplest strategy is to use static routes, and this would be considered first for stub areas. If there are no stub areas in the network, or when a routing protocol is indicated, then RIP or RIPv2 should be considered. Recall that RIP/RIPv2 are recommended for networks with low to medium hierarchy and interconnectivity. When the network increases to a high degree of hierarchy and interconnectivity, OSPF should be considered. The approach is to apply static routes first for stub areas, then RIP/RIPv2 when network hierarchy and interconnectivity are low to medium, then OSPF when network hierarchy and interconnectivity are high. BGP is applied when an EGP is required in the network.

Since we are starting with the simplest routing mechanism (static routes) and working our way up to more complex mechanisms, we usually start with the outer edges of the network, where hierarchy and interconnectivity is lowest, and work our way toward the center, or backbone, of the network, where hierarchy and interconnectivity are highest (Figure 6.26).

Click To expand
Figure 6.26: Example application of static routes, IGPs, and EGPs in a network.

The idea is to start simple and add a more complex routing protocol only when needed. When a more complex routing protocol is needed, however, we need to reevaluate previous choices, not just add the protocol to the network. As a result of reevaluating previous choices, we may decide to keep them and just add the new routing protocol to the network, or we may decide to replace the previous routing protocol with the new one. The intent is to keep the number of routing protocols to a minimum and to avoid having multiple instances of the same routing protocol in different areas of the network. With this in mind, the third recommendation may be extended as follows:

3a. | When static routes have previously been chosen and RIP/RIPv2 has been chosen as the routing protocol for another area of the network, RIP/RIPv2 replaces static routes for those areas where static routes were chosen.
3b. | When RIP/RIPv2 has previously been chosen and OSPF has been chosen as the routing protocol for another area of the network, OSPF replaces RIP/RIPv2 for those areas where RIP/RIPv2 was chosen.
3c. | BGP, when required for a backbone network, may replace OSPF or RIP/RIPv2 if they were previously chosen for the backbone.

Although keeping the number of routing protocols in the network to a minimum is recommended, there are times when the benefits of having more than one IGP may out-weigh the costs of their support and maintenance. When the network hierarchy and interconnectivity is high enough to warrant changing the routing protocol from RIP/RIPv2 to OSPF, the areas where RIP/RIPv2 or static routes are already assigned are then reevaluated. There may be areas where OSPF is beneficial and other areas where it does not offer any additional benefits and may increase support or maintenance costs.

There may also be times when applying BGP within the network, with either RIP/RIPv2 or OSPF, is appropriate. Applying BGP within the network may be considered when the network is so large that it should be fragmented into multiple ASs or when the organizations within the network want administrative, management, or security autonomy. In such cases, the boundary between the organizations could be treated as a hard boundary.

One thing to consider when mixing routing protocols is how information is to be translated between routing protocols. Information such as network masks, protocol metrics, policies, or AS information can easily be lost or misrepresented when translating between routing protocols. There is currently no standard metric translation between dissimilar routing protocols.

In applying routing protocols, we start by evaluating the degrees of hierarchy and interconnectivity of each FA and considering any other factors for that FA, or features of the routing protocols that may apply. When a change is made in the choice of routing protocol, such as from static routes to RIP/RIPv2, from RIP/RIPv2 to OSPF, or from RIP/RIPv2/OSPF to BGP, reevaluate FAs where routing protocols or static routes have already been chosen. In general, RIP/RIPv2 supersedes static routes, and OSPF supersedes RIP/RIPv2, but remember that you can also consider combining the protocols within the network. Figure 6.27 illustrates the process of applying routing protocols.

Click To expand
Figure 6.27: Iterative evaluation of routing protocols.

FAs that contain only backbone networks should be considered last because they are usually the most complex. It is therefore likely that the backbone networks will require the most complex routing protocols. This is where BGP may be considered. In general, for the backbone network:

  1. If all FAs are using the same routing protocol, that protocol should be considered first for the backbone.

  2. When multiple routing protocols are chosen for the network, consider the more complex protocol for the backbone first.

  3. When the backbone interconnects ASs, or when organizations require autonomy in interfacing to the backbone, consider BGP as the routing protocol for the backbone.

The decisions developed in choosing and applying routing protocols should be documented as part of the addressing and routing architecture. Showing the decisions for each area of the network, as in Figures 6.26 and 6.27, is a start toward this documentation.


6.8 Architectural Considerations

In developing our addressing and routing architecture, we need to evaluate the sets of internal and external relationships for this component architecture.

6.8.1 Internal Relationships

Depending on the type of network being developed, the set of candidate addressing and forwarding mechanisms for a component architecture can be quite different. For example, a service-provider network may focus on mechanisms such as supernetting, CIDR, multicasts, peering, routing policies, and confederations, whereas the focus of a medium-sized enterprise network would more likely be on private addressing and NAT, subnetting, VLANs, switching, and the choice and locations of routing protocols.

Two types of interactions are predominant within this component architecture: (1) trade-offs between addressing and forwarding mechanisms and (2) trade-offs within addressing or within forwarding. Addressing and forwarding mechanisms influence the choice of routing protocols and where they are applied. They also form an addressing hierarchy upon which the routing hierarchy is overlaid.

An example of this is shown in Figure 6.28. This figure illustrates interactions within the addressing/forwarding architecture. Within this architecture, routing protocol selection, either by itself or in combination with VLAN addressing, determines ISP path selection.

Click To expand
Figure 6.28: Example of interactions within addressing/routing architecture.

Areas of the network where dynamic addressing, private addressing, and NAT mechanisms are applied will affect how routing will (or will not) be provided in those areas.

6.8.2 External Relationships

External relationships are trade-offs, dependencies, and constraints between the addressing/routing architecture and each of the other component architectures (network management, performance, security, and any other component architectures you may develop).

There are common external relationships between addressing/routing and each of the other component architectures, some of which are presented in the following subsections.

Interactions between Addressing/Routing and Network Management

Addressing/routing can be used to configure boundaries for network management. For example, AS boundaries indicate where one management domain ends and another begins.

Interactions between Addressing/Routing and Performance

Performance can be closely coupled with addressing/routing through mechanisms such as MPLS, differentiated and integrated services, and Resource Reservation Protocol. However, when routing protocol simplicity is a high priority, performance may be decoupled from addressing/routing.

Performance can also be coupled with addressing/routing through the use of IPv6, which provides information fields that can be used by performance mechanisms.

Interactions between Addressing/Routing and Security

Security mechanisms are often intrusive, intercepting, inspecting, and controlling network access and traffic. As such, they can have an impact on the routing behavior of the network. Just as security perimeters or zones bound performance (see Chapter 8), they can also bound routing.

NAT can be used to enhance security and provide private addressing space for a network. By forming a boundary between private and public address spaces, with translation of addresses between these spaces, outside access to the network can be more controlled. Addressing and routing can affect security in three ways:

  1. In terms of accessing the network from the outside (firewalls, IP hiding, and NAT)

  2. How protective measures are implemented on servers (e.g., access control lists restrict access based on IP address and subnet)

  3. Ability to trace an attack inside the perimeter

The use of dynamic addressing can create problems in tracing network events. Positioning some services (e.g. public address Web servers) outside the firewall or behind the firewall (with only http permitted through the firewall) is an important decision. Wrappers will not control access if the IP address space is dynamic. Also, permitting only certain protocols to talk to a server from a well-known address space is an option if the network is designed with this in mind. Last, properly routing hostile packets is an option with the right architecture.


6.9 Conclusion

Addressing and routing provide the basic functionality for forwarding user and network management traffic through the network. In developing the addressing/routing architecture, you must understand the fundamental concepts behind addressing and routing and how they are used to provide hierarchy and interconnectivity in the network.

This chapter provides some new ways of looking at routing, routing flows, and routing protocols. We used WGs and FAs to develop hard and soft boundaries for routing flows and then applied a number of techniques to manipulate these flows. These mechanisms, combined with evaluating and choosing routing protocols for the network, as well as where to apply the various addressing strategies, provide a picture of addressing and routing for the network that will enable you to optimize the forwarding of traffic flows through your network.


6.10 Exercises

  1. Represent each address below in binary format. What is the class of each address?

    1. 192.12.102.0

    2. 10.20.30.100

    3. 130.5.77.15

  2. For each of the following address/prefix length pairs, give its natural mask (in dotted-decimal notation), its subnet/supernet mask (also in dotted-decimal notation), and the range of networks or subnets permitted by the mask. Also describe any problems and limitations with the address/mask pairs, if any.

    1. 129.99.0.0/16

    2. 136.178.0.0/22

    3. 198.9.9.0/28

    4. 192.92.240.0/20

    5. 192.92.243/20

  3. Subnet 136.178.0.0 into 16 subnets. Show the binary and dotted-decimal forms of each subnet, as well as the subnet mask.

    Refer to Figure 6.29 (p. 294) for Exercises 4 through 7.

    Click To expand
    Figure 6.29: Diagram for Exercises 4 through 7.

  4. Where are the FAs for this network design?

  5. Where are the potential logical and physical boundaries for this network design?

  6. Given the network address 129.99.0.0/16, develop a variable-length addressing scheme that best fits the design, with the following numbers of users:

    AS Number

    Location

    Department

    Users

    1

    Chicago Campus Building 1

    Legal

    120

    Accounting

    370

    Chicago Campus Building 2

    HQ

    1580

    Engineering

    200

    2

    Toronto

    Sales

    75

    Boston

    Sales

    110

    3

    Philadelphia

    Operations1

    2150

    Operations2

    975

    Sales

    575

  7. You are using BGP4 in the WAN between AS1, AS2, and AS3. Describe in plain text or as BGP4 policy statements how you would achieve the following:

    1. Permit AS3 to communicate with AS1 but do not allow AS2 to communicate with AS1.

    2. Allow both AS2 and AS3 Internet access through AS1 only between 6 PM and 6 AM EST each night.

    Refer to RFC 1771 for specifics on the BGP4 specification.

  8. Consider the following: You are an ISP and have a group of addresses (CIDR blocks) to allocate to your customers. You have allocated addresses to a number of customers from a CIDR block of 198.9.128.0/18 (equivalent to the block of Class C addresses 198.9.128.0 through 198.9.191.0). Now one of your clients wants to stop using your ISP service and wants move to another ISP while keeping the /24 that you had allocated to it (198.9.145.0/24). You are in a dilemma; you cannot take back this address (your customer's lawyers are better than yours!), yet advertising a CIDR block that contains that address seems to break the rules of CIDR routing.

    1. Show how routing based on the longest (most specific) match allows you to continue advertising this CIDR block.

    2. Show what happens to the ex-customer's traffic if there is a bug in the Internet and their route gets dropped.

  9. Many network designs are requiring redundant access to the Internet, with the backup connection either in a hot-standby mode or load balancing between the two connections. Using BGP4, outline a strategy for providing a backup Internet connection for the following cases:

    1. The backup Internet connection is in a hot-standby mode and can be made operational with a change in the routing configuration.

    2. The backup Internet connection is fully operational, and there is load balancing between the primary and backup connections.


Chapter 7: Network Management Architecture

Our next component architecture is for network management. Proper network management is critical to the success of any network, and as you will see, there are many factors to consider in providing network management.

7.1 Objectives

In this chapter, you will learn about network management and the network management architecture. We will discuss the various functions of network management and the mechanisms used to achieve these functions. We will discuss and compare a number of variations for the network management architecture, as well as the internal and external relationships for network management.


7.2 Preparation

To be able to understand and apply the concepts in this chapter, you should be familiar with network management protocols (Simple Network Management Protocol [SNMP] and optionally Common Management Information Protocol [CMIP]/CMIP over TCP/IP [CMOT]), the utilities ping, traceroute, and TCPdump, management information base (MIB) structures and parameters, and operations support system (OSS) functions. Some recommended sources of information include:

  • SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, by William Stallings, Addison-Wesley Publishing, January 1999

  • Understanding SNMP MIBs, by David Perkins and Evan McGinnis, Prentice Hall, December 1996

  • Simple Network Management Protocol (SNMP), STD 0015,[1] by J. D. Case, M. Fedor, M. L. Schoffstall, and C. Davin, May 1990

[1]All Internet Engineering Task Force requests for comments and STDs can be found at www.ietf.org.


7.3 Background

Network management consists of the set of functions to control, plan, allocate, deploy, coordinate, and monitor network resources. Network management has often been an afterthought in most network architectures. For example, most network architectures and designs were developed without a focus on users being malicious, which was generally true until a few years ago. Consider, for example, the changes that have been made in SNMP security. Today, and in the future, networks are a resource whose integrity must be measurable and verifiable.

The network management architecture, as with the other component architectures, begins with the requirements and flow analyses. Areas that should be addressed during the analysis process include:

  • Deciding which network management protocol to apply

  • Implementing high-level asset management as part of the network management architecture

  • Reconfiguring the network often to meet various different requirements

  • Monitoring the entire system from a single location or device

  • Testing service-provider compliance with service-level agreements (SLAs) and policies

  • Proactively monitoring (discovering performance problems before users, applications, and devices are affected by them)

  • Fulfilling requirements for out-of-band access

We will begin this chapter by defining and characterizing management for a network architecture and discuss how to plan for monitoring, configuring, and troubleshooting the planned network. We will then examine network management protocols and instrumentation requirements. This will lead to considerations for developing the network management architecture.


7.4 Defining Network Management

Network management can be viewed as a structure consisting of multiple layers:

Business management: This is the management of the business aspects of a network, for example, the management of budgets/resources, planning, and agreements.

Service management: This is the management of delivery of services to users; for example, for service providers, this would include the management of access bandwidth, data storage, and application delivery.

Network management: This is the management of all network devices across the entire network.

Element management: This is the management of a collection of similar network devices, for example, access routers or subscriber management systems.

Network-element management: This is the management of individual network devices, for example, a single router, switch, or hub.

This structure is a top-down approach, with the most abstract component (business management) at the top of the hierarchy and the most specified, concrete component (network-element management) at the bottom of this hierarchy. This is shown in Figure 7.1.

Click To expand
Figure 7.1: Network management hierarchy.

Correspondingly, as the components become more abstract, the ways that they are applied and measured (their information elements) change. Thus, at the bottom of this hierarchy (network-element, element, and network), management is applied with variables and parameters, and at the top of this hierarchy (service and business), management is applied in more abstract terms, using policies. This is common to all architectural components, and we will find that policies can be used for each component.

Network management can be divided into two basic functions: the transport of management information across the system and the management of network management information elements (Figure 7.2).

Click To expand
Figure 7.2: Network management is composed of managing elements and transporting management data.

These functions, as shown in Figure 7.2, consist of a variety of tasks—monitoring, configuring, troubleshooting, and planning—that are performed by users, administrators, and network personnel. One of the first challenges in developing a network management architecture is to define what network management really means to the organizations that will be performing the tasks and receiving the end services—the users, or customers, of the system.

There are four categories of network management tasks that we will consider here, corresponding to the four tasks mentioned earlier:

  • Monitoring for event notification

  • Monitoring for trend analysis and planning

  • Configuring network parameters

  • Troubleshooting the network

7.4.1 Network Devices and Characteristics

A network device is an individual component of the network that participates at one or more of the protocol layers. This includes end devices, routers, switches, data service units (DSUs), hubs, and network interface cards (NICs). Network devices have characteristics that can be measured. They are grouped into end-to-end and per-link/per-network or per-element characteristics, as shown in Figure 7.3.

Click To expand
Figure 7.3: Network characteristics can be per element, per link, per network, or end-to-end.

End-to-end characteristics are those that can be measured across multiple network devices in the path of one or more traffic flows and may be extended across the entire network or between devices. Examples of end-to-end characteristics for network devices are availability, capacity, delay, delay variation (jitter), throughput, error rates, and network utilization. These characteristics may be modified or added to depending on the types of traffic on the network.

Per-link/per-network and per-element characteristics are those that are specific to the type of element or connection between elements being monitored. These characteristics may be used individually or may be combined to form an end-to-end characteristic. Examples of per-link characteristics are propagation delay and link utilization, and examples of per-element characteristics include (for an IP router) IP forwarding rates (e.g., in IP packets per second), buffer utilization for the router, and any logs of authentication failures.

Management of network devices and networks includes network planning (e.g., cell site planning for wireless), initial resource allocation (e.g., frequency or bandwidth allocations), and fault, configuration, accounting, performance, and security (FCAPS) from the telecommunication network management model.


7.5 Network Management Mechanisms

We will now take a look at some of the popular management mechanisms, including network management protocols. There are currently two major network management protocols: SNMP and CMIP. CMIP includes CMOT. These network management protocols provide the mechanism for retrieving, changing, and transport of network management data across the network.

SNMP has seen widespread use and forms the basis for many popular commercial and public network management systems. It provides facilities for collecting and configuring parameters from network devices. These are done through the SNMP commands get (to collect the value of a parameter), get-next (to collect the value of the next parameter in the list), and set (to change the value of a parameter). There are also provisions for the unsolicited notification of events, through the use of traps. A trap is a user-configurable threshold for a parameter. When this threshold is crossed, the values for one or more parameters are sent to a specified location. A benefit of trap generation is that polling for certain parameters can be stopped or the polling interval lengthened, and instead an automatic notice is sent to the management system when an event occurs.

Parameters that are accessible via SNMP are grouped into MIBs. Parameters can be part of the standard MIB (MIB-II), other standard MIBs (typically based on a type of network device, technology, or protocol), remote monitoring MIBs, or enterprise-specific MIBs, which have parameters that are specific to a particular vendor's product.

SNMP version 3 (SNMPv3) builds on the previous versions of SNMP, providing more secure authentication, the ability to retrieve blocks of parameters, and trap generation for most parameters. When SNMP is mentioned in this book, it refers to SNMPv3 unless otherwise noted.

CMIP/CMOT provides for parameter collection and setting, as with SNMP, but also allows for more types of operations. Many CMIP/CMOT features, such as globally unique object naming, object classification, alarm reporting, audit trails, and test management, can also be provided by SNMP by creating new MIBs and tools to support such abstractions.

In general, SNMP is simpler to configure and use than CMIP/CMOT, helping make it widely accepted. It is usually easier to instrument network devices with SNMP. SNMP is used in monitoring, instrumentation, and configuration mechanisms, all of which are discussed in the following sections.

7.5.1 Monitoring Mechanisms

Monitoring is obtaining values for end-to-end, per-link, and per-element characteristics. The monitoring process involves collecting data about the desired characteristics, processing some or all of these data, displaying the (processed) data, and archiving a subset of these data.

Data are usually collected through a polling (actively probing network devices for management data) or monitoring process involving a network management protocol (e.g., SNMP) or proxy service. As we will see later in this chapter, several techniques may be used to get this data, as well as to ensure that the data are current and valid. When the data are gathered, they may or may not reflect the characteristics we wish to monitor. Values for some characteristics may have to be derived from the gathered data, and other values may be modified (e.g., added, subtracted, time averaged). This is processing of the data.

Sets of raw (unprocessed) and processed data will need to be displayed. There are different types of displays you may use, including standard monitor displays, field-of-view or wide-screen displays, and special-purpose displays. Along with choosing displays, you will also want to consider how the data will be shown to the user, administrator, or manager. There are several techniques to display data, such as logs and textual displays, graphs and charts (both static and moving), and alarms. Some data may be abstracted by symbols, such as showing parts of the network as a cloud.

At some time during this process, some or all of the data are saved to a (semi) permanent media or system. This part of the process may have multiple steps, including primary storage, the staging of data for short periods, which could be at the network management server; secondary storage, the aggregation of data from multiple primary storage sites, at a storage server for the network; and tertiary storage, which is usually the most permanent—and slowest—storage within the network. Secondary and tertiary storage is often termed storage archives. Figure 7.4 shows each part of this process occurring on a separate device, but they may all be combined on a single device.

Click To expand
Figure 7.4: Elements of the monitoring process.

Monitoring for Event Notification

An event is something that occurs in the network that is worthy of noting. This may be a problem or failure in a network device, across the network, or when a characteristic crosses a threshold value. It may only be something that is informational to the user, administrator, or manager, such as notification of an upgrade. Events may be noted in a log file, on a display, or by issuing an alarm, depending on the level of priority of the event. Events are similar to transients, which are short-lived changes in the behavior of the network. Thresholds or boundaries may be set on end-to-end, per-link, or per-element characteristics for short-term or immediate notification of events and transients. This is termed here real-time analysis.

Figure 7.5 shows an example of such monitoring. Ping is used to gather round-trip delay information, which is presented as a chart on the monitoring system. A threshold of 100 ms has been chosen for this display. When this threshold is crossed, it triggers an alarm to notify the network manager that a problem may exist in the network.

Click To expand
Figure 7.5: Monitoring for event notification.

Real-time analysis usually requires short polling intervals (time periods between active probing of the network and network devices for management data), and there is a trade-off between the number of characteristics and network devices polled for real-time analysis versus the amount of resources (capacity, CPU, memory, storage) needed to support such analysis.

In some cases the amount of network data generated (and the resulting traffic) by the periodic polling of multiple characteristics on many network devices can affect the overall performance of the network. For example, consider a network that has 100 network devices, with each element having an average of four interfaces and each interface being monitored for eight characteristics; this would be added up as follows:

(100 network devices) × (4 interfaces/network device) × (8 characteristics/interface) = 3200 characteristics

If each of the 3200 characteristics generates an average of 8 bytes of data and an estimated 60 bytes of protocol overhead, the amount of data generated per polling session is as follows:

(3200 characteristics) × (8 bytes = 60 bytes) = 217.6 KB of traffic, or 1.74 Mb of traffic

If we plan to poll with a polling interval of 5 seconds, at best this 1.74 Mb of traffic would be spread out over the 5 seconds, or 384 Kb/s. It is more likely, however, that most of the data will arrive shortly after the polls are generated, so the traffic may be more like a spike of 1.74 Mb for the second after the polls occur.

For a period of 1 day, the total amount of traffic will be

(1.75 Mb/polling interval) × (720 polling intervals/h) × (24 hours/day) = 30.2 Gb of traffic

And the amount of data stored would be

(3200 characteristics/polling interval) × (8 bytes) × (720 polling intervals/day)× (24 hours/day) = 442 MB data stored per day

Over the course of a year, this would add up to more than 161 GB of data. And this is a conservative estimate for a mid-range enterprise environment.

Monitoring for Trend Analysis and Planning

The same end-to-end, per-link, and per-element characteristics that are used for event monitoring can also be used for trend analysis. Trend analysis is using network management data to determine long-term network behaviors, or trends. This is useful in planning for future network growth.

In doing continuous, uninterrupted data collection, usually with long polling intervals (minutes or hours instead of seconds), we can begin by establishing baselines for trends and then use these baselines to plot trend behavior. This is shown in Figure 7.6, which shows long-term trends for availability, delay, and percentage of utilization. Polls for each characteristic are saved to network management on a regular basis, and over a long period (usually weeks or months, but sometimes up to years), trends in these characteristics begin to emerge. In Figure 7.6, upward trends are clearly visible for delay and percentage of utilization.

Click To expand
Figure 7.6: Monitoring for metrics and planning.

7.5.2 Instrumentation Mechanisms

Instrumentation is the set of tools and utilities needed to monitor and probe the network for management data. Instrumentation mechanisms include access to network management data via SNMP, monitoring tools, and direct access. Instrumentation can be coupled with monitoring, display, processing, and storage to form a complete management system.

SNMP (currently as version 3) provides access to MIB variables, including those in MIB-II, other standard MIBs (e.g., DS1 MIB), enterprise-specific MIBs, and other monitoring MIBs (remote monitoring [RMON]), switch monitoring, and ATM monitoring). SNMP is the most common method for accessing network management data. Several commercially and publicly available monitoring software packages use SNMP for data access.

Monitoring tools include utilities such as ping, traceroute, and TCPdump, and direct-access mechanisms include telnet, FTP, TFTP, and connections via a console port.

An example of a base set of parameters to monitor can be developed from the standard MIB-II. The following parameters can be collected on a per-interface basis:

ifInOctets | Number of bytes received
ifOutOctets | Number of bytes sent
ifInUcastPkts | Number of unicast packets received
ifOutUcastPkts | Number of unicast packets sent
ifInNUcastPkts | Number of multicast/broadcast packets received
ifOutNUcastPkts | Number of multicast/broadcast packets sent
ifInErrors | Number of erroneous packets received
ifOutErrors | Number of packets that could not be sent

These parameters can be used for both short-term event monitoring and longterm trend analysis of throughput and error rates. In addition, the following parameter may be collected to determine availability:

ifOperStatus

State of an interface (up, down, testing)

This parameter could be used in conjunction with monitoring tools such as ping to verify availability.

In developing the network management architecture, you should collect the instrumentation requirements for each type or class of network device, such as forwarding elements (e.g., routers, switches, hubs), pass-through elements (e.g., DSUs, simple concentrators, simple bridges), and passive devices such as those that use RMON.

A consideration for the network management architecture is to ensure that the instrumentation is accurate, dependable, and simple. There are a couple of ways to ensure accuracy in the instrumentation: testing and taking alternative measurements. If a lab environment is available, some limited network conditions can be replicated and tested. For example, generating known quantities of traffic by devices and/or traffic generators and comparing the results in the routers with those from the devices/traffic generators can test packet-forwarding rates in routers.

Sometimes, parameters can be verified from the current network. Taking alternative measurements of the same parameter at different points in the network is one way to verify parameters. We may be able to get link-layer data from DSUs, routers, and switches in the path of a flow, and by comparing the various sources of data, we can determine whether and where there are discrepancies in parameter measurements.

For a network management system to work properly, the instrumentation needs to be dependable. A network management system is useless if it is the first thing to crash when network problems occur. This may seem obvious, but few current management systems are truly robust and dependable. Ways that dependability can be enhanced in the architecture are to physically separate and replicate the management components. By having multiple systems collecting, processing, displaying, and storing management data for different parts of the network and by building hierarchy in the management data flows, you will make the loss of any single component of the management system have less of an impact on the network's manageability. This is covered in more detail later in this chapter.

7.5.3 Configuration Mechanisms

Configuration is setting parameters in a network device for operation and control of that element. Configuration mechanisms include direct access to devices, remote access to devices, and downloading configuration files (Figure 7.7):

  • SNMP set commands

  • Telnet and command line interface (CLI) access

  • Access via HTTP

  • Access via common object request broker architecture (CORBA)

  • Use of FTP/TFTP to download configuration files

Click To expand
Figure 7.7: Configuration mechanisms for network management.

As part of this process, we want to generate a working set of end-to-end, per-link, and per-element characteristics and plan for the architecture and design to have the facilities to monitor these characteristics at short- and long-term polling intervals. Later in this chapter, we will develop some guidelines on where monitoring facilities should be placed in the network.

Many network devices require some degree of configuration by network personnel. For each type or class of network device (e.g., Brand X router, Ethernet switch), we want to generate a table of configuration parameters, establish the methods for configuring these parameters, and understand the effects of changing each parameter (when possible). To properly manage a network, we must understand how configuration parameters affect each network device.

We also need to understand the effects of problems with network devices and how to correct such problems. Troubleshooting, which consists of problem notification, isolation, identification, and resolution, can be aided by knowing likely failure modes in the network, their effects, and any possible steps to correct them.

It should be noted that, in generating a set of working characteristics, configuration parameters, and failure modes, we are going through a detailed review of how the network will operate. The result is that you will better understand what will happen in the network.


7.6 Architectural Considerations

The network management process consists of choosing which characteristics of each type of network device to monitor/manage; instrumenting the network devices (or adding collection devices) to collect all necessary data; processing these data for viewing, storage, and/or reporting; displaying a subset of the results; and storing or archiving some subset of the data.

Network management touches all other aspects of the network. This is captured in the FCAPS model:

  • Fault management

  • Configuration management

  • Accounting management

  • Performance management

  • Security management

In this model, fault management consists of processing events and alarms (where an alarm is an event that triggers a real-time notification to network personnel); identifying, isolating, troubleshooting, and resolving problems; and returning the network to an operational state.

Configuration management consists of setting system parameters for turnup; provisioning the network; configuring the system and generating backups and restores; and developing and operating system databases.

Accounting management consists of monitoring and managing subscriber service usage and service billing.

Performance management consists of implementing performance controls, based on the IP services architecture; collecting network and system performance data; analyzing this performance data; generating short- and long-term reports from these data; and controlling network and system performance parameters.

Finally, security management consists of implementing security controls, based on the security architecture; collecting and analyzing security data; and generating security reports and logs from these data.

The network management process and management model both provide input to the network management architecture. With the knowledge of what network management means for our network, we can consider the following in the architecture:

  • In-band and out-of-band management

  • Centralized, distributed, and hierarchical management

  • Scaling of network management traffic

  • Checks and balances

  • Management of network management data

  • MIB selection

  • Integration into OSS

7.6.1 In-Band and Out-of-Band Management

In-band management occurs when the traffic flows for network management follow the same network paths as the traffic flows for users and their applications. This simplifies the network management architecture, for the same network paths can be used for both types of data and a separate path (and possibly network) is not required (Figure 7.8).

Click To expand
Figure 7.8: Traffic flows for in-band management.

A trade-off with in-band management is that management data flows can be affected by the same problems that have an impact on user traffic flows. Since part of network management is troubleshooting problems in the network, it will be negatively affected if the management data flows are delayed or blocked. At the times when network management is most needed, it may not be available. Also, a primary objective of the network management architecture is to be able to do event monitoring when the network is under stress, for example, when congested with traffic, suffering from network hardware/software configuration problems, or under a security attack.

Out-of-band management occurs when different paths are provided for network management data flows and user traffic flows. This type of management has the distinct advantage of allowing the management system to continue to monitor the network during most network events, even when such events disable the network. This allows you to effectively see into portions of the network that are unreachable through normal paths (e.g., user data flow paths).

Out-of-band management is usually provided via a separate network, such as frame relay, ATM, or plain old telephone service (POTS) connections. Figure 7.9 illustrates this point. An advantage of having a separate network is that additional security features can be integrated into this (network management) network. Given that this network provides access to most or all network devices, having additional security here is important. Another advantage is that the out-of-band connection can be used to troubleshoot and configure network devices that are in remote locations. This saves time and resources when the user data network is down and remote network devices need to be accessed.

Click To expand
Figure 7.9: Traffic flows for out-of-band management.

Whenever out-of-band management is planned, a method to check and verify its availability is needed. This can be as simple as planning to use out-of-band management on a regular basis, regardless of need. This will help ensure that problems with out-of-band management are detected and solved while the network is still healthy.

A trade-off with out-of-band management is the added expense and complexity of a separate network for network management. One way to reduce the expense is to provide out-of-band monitoring at a low level of performance, relative to the user data network. For example, out-of-band monitoring may be achieved by using phone lines. Although this may be cheaper than providing dedicated network connections, it will require time to set up (e.g., call) the out-of-band connections and the capacity of each connection may be limited.

For some networks a combination of in-band and out-of-band management is optimal (Figure 7.10). Usually this is done when the performance of the user data network is needed to support network management data flows (for monitoring the operational network), but the separate, out-of-band network is needed when the user data network is down.

Click To expand
Figure 7.10: Combination of in-band and out-of-band management traffic flows.

Some trade-offs of having a combination of in-band and out-of-band management are that the expense of a separate network is still incurred and security issues on the user data network still need to be addressed.

7.6.2 Centralized, Distributed, and Hierarchical Management

Centralized management occurs when all management data (e.g., ping packets, SNMP polls/responses, traceroute) radiate from a single (typically large) management system. The flows of management data then behave like the client-server flows discussed in Chapter 4 and shown in Figure 7.8.

The obvious advantage to centralized management is that only one management system is needed, simplifying the architecture and reducing costs (depending on the choice of management system). A centralized management system often has a variety of management tools associated with it.

Some trade-offs to centralized management are that the management system is a single point of failure and that all management flows converge at the network interface of the management system, potentially causing congestion or failure.

Distributed management occurs when there are multiple separate components to the management system, and these components are strategically placed across the network, localizing network management traffic and distributing management domains. In Figure 7.11, multiple local element management systems (EMSs) are used to distribute management functions across several domains.

Click To expand
Figure 7.11: Distributed management where each local EMS has its own management domain.

In distributed management, either the components provide all management functions (monitoring, display, storage, and processing) or the distributed components are the monitoring devices. For example, distributed management may take the form of having multiple management systems on the network (e.g., one management system per campus or per management domain, as shown in Figure 7.11) or a single management system with several monitoring nodes, as in Figure 7.12.

Click To expand
Figure 7.12: Distributed management where monitoring is distributed.

Advantages to distributed management are that the monitoring devices act to localize the data collection, reducing the amounts of management data that transit the network. They may also provide redundant monitoring so that other monitoring devices on that network can cover the loss of any single monitoring device.

A trade-off with distributed management is that costs will increase with the number of monitoring devices or management systems needed.

Hierarchical management occurs when the management functions (monitoring, display, storage, and processing) are separated and placed on separate devices. Management is hierarchical because when the functions are separated, they can be considered layers that communicate in a hierarchical client-server fashion (see Chapter 4 for a discussion about hierarchical client-server flows). Figure 7.13 shows the structure of a hierarchical management system.

Click To expand
Figure 7.13: Hierarchical management separates management into distinct functions that are distributed across multiple platforms.

In hierarchical management, localized monitoring devices collect management data and either pass these data directly to display and storage devices or to monitoring devices to be processed. When the management data are passed on to display and storage devices without processing, the monitoring devices act as they did in distributed management, localizing the data collection and reducing the amounts of management data that transit the network.

When the management data are processed before being sent to display and storage devices, the monitoring devices act as local filters, sending only the relevant data (e.g., deltas on counter values or updates on events). This may substantially reduce the amount of management data in the network, which is especially important if the monitoring is in-band.

Thus, we can have monitoring devices at strategic locations throughout the network, polling local devices and network devices, collecting and processing the management data, and forwarding some or all of these data to display and storage devices. The numbers and locations of each type of device will depend on the size of the network, the amount of management data expected to be collected (discussed later in this chapter), and where the displays and storage devices are to be located in the network management architecture.

An advantage to hierarchical management is that every component can be made redundant, independent of the other components. Thus, it can be tailored to the specific needs of your network. In some networks, it may be preferable to have several display devices, whereas in other networks, having several processing devices or storage devices may be preferable. These components are separate, so the amounts of each can be individually determined.

A trade-off in hierarchical management is the cost, complexity, and overhead of having several management components on the network.

7.6.3 Scaling of Network Management Traffic

Some recommendations are presented here to help determine and optimize the capacity requirements of network management traffic.

Recommendation 1

For a LAN environment, start with one monitoring device per IP subnet. For each subnet, estimate values for the following traffic variables:

  • Number of devices and network devices to be polled

  • An average number of interfaces per device

  • Number of parameters to be collected

  • Frequency of polling (polling interval)

Combining these variables will give you an estimate of the average data rate for management traffic per subnet. If the combined variable rate is greater than approximately 10% of the capacity (line rate) of the LAN, you may want to consider reducing the amount of management traffic generated by reducing one or more of the aforementioned variables. When the estimated average rate is less than 1% of LAN capacity, this indicates that it may be possible to increase one or more of the variables.

For most of the standard LAN technologies (Ethernet, Fast Ethernet, Gigabit Ethernet, Token Ring, FDDI), the management traffic rate should be targeted at 2% to 5% of the LAN capacity. As LAN capacity increases, you will have more available capacity for network management traffic and may choose to increase one or more traffic variables (Figure 7.14).

Click To expand
Figure 7.14: Scaling network management traffic.

Recommendation 2

For a WAN environment, start with one monitoring device per each WAN-LAN interface. This is in addition to any monitoring devices indicated in Recommendation 1. However, if a monitoring device is on a LAN subnet that is also the WAN-LAN interface, that device may be used to collect data for both the LAN and the WAN. Placing a monitoring device at each WAN-LAN interface allows us to monitor the network at each location, as well as measure, verify, and possibly guarantee services and performance requirements across the WAN.

7.6.4 Checks and Balances

Checks and balances are methods to duplicate measurements in order to verify and validate network management data. While doing checks and balances adds effort to the network management process, it is advisable to have more than one method of collecting network management data, particularly for data that are considered vital to the proper operation of the network. SNMP agent and MIB implementations are vendor implementation specific and are not guaranteed to provide data that are consistent across all vendors.

Objectives of performing checks and balances are to locate and identify the following:

  • Errors in recording or presenting network management data

  • Rollovers of counters (e.g., returning a counter value to zero without proper notification)

  • Changes in MIB variables from one software version to another

In addition, checks and balances help normalize network management data across multiple vendors by verifying data through measurements from multiple sources.

Collected management data should be verified for accuracy. For example, when polling for SNMP variables for an interface, consider RMON polling as well to verify these data. Consider using a traffic analyzer to verify data for various random periods. You may also run independent tests with traffic generators, the vendors' network devices, and data-collection devices to verify the accuracy of collected data.

7.6.5 Management of Network Management Data

Flows of network management data typically consist of SNMP parameter names and values, and the results of queries from utilities such as ping or traceroute. These data are generated by network devices and other devices on the network, transported via SNMP to monitoring devices, and possibly forwarded to display and storage devices. It is important to the network management architecture that we understand where and how the data are generated, transported, and processed; this will help us to determine where network management components may be placed in the network.

Management data may be generated either in a query/response (stateless) method, as with SNMP or ping queries, or in response to a prearranged set of conditions (stateful), as with SNMP traps. Large numbers of SNMP queries should be spread out over a time interval (e.g., polling interval), not only to avoid network congestion but also to avoid overburdening network devices and monitoring devices with the processing required to generate management data.

Management data will consist of frequently generated parameters for real-time event notification and less frequently generated (or needed) parameters for trend analysis and planning. The same parameters may be used for both purposes. Since frequent polling can generate large amounts of data, storage of these data can become a problem. Some recommendations for managing these data are presented in the following sections.

Recommendation 1—Local Storage versus Archival

Determine which management data are necessary to keep stored locally and which data may be archived. Management data are usually kept local, cached where they can be easily and quickly retrieved, for event analysis and short-term (on the order of hours or days) trend analysis. Management data that are not being used for these purposes should be archived to secondary or tertiary storage, such as tape archives or offsite storage (Figure 7.15).

Click To expand
Figure 7.15: Local and archival storage for management data.

Recommendation 2—Selective Copying of Data

When a management parameter is being used for both event notification and trend analysis, consider copying every Nth iteration of that parameter to a separate database location, where the iteration size N is large enough to keep the size of these data relatively small yet is small enough so the data are useful in trend analysis. In Figure 7.16, SLA variables are polled regularly (each variable polled per second), and every Nth poll is saved in long-term storage (archival). Depending on the bandwidth and storage available for network management traffic, N can range from 102 to 105.

Click To expand
Figure 7.16: Selective copying to separate database.

A trade-off in selective copying of data is that whenever data are copied, some data may be lost. To help protect against this risk, you can use TCP for data transmission or send copies of data to multiple archival systems (e.g., 1 primary 1 redundant).

If there are indications that more immediate analysis needs to be done, then either a short-term trend analysis can be done on the locally stored data (from Recommendation 1) or the iteration size N can be temporarily shortened.

Recommendation 3—Data Migration

When management data are collected for trend analysis, data can be stored locally to the management device then downloaded to storage/archival when traffic is expected to be low (e.g., at night). In Figure 7.17, polls of network management data are made in 5-minute intervals and stored locally. These data are then downloaded to archival storage once or twice daily, usually when there is little user traffic on the network (e.g., at 2 AM).

Click To expand
Figure 7.17: Data migration.

Recommendation 4—Metadata

Metadata include additional information about the collected data, such as references to the data types, time stamps of when the data were generated, and any indications that these data reference any other data. A management data archival system should provide such additional information regarding the data that have been collected.

7.6.6 MIB Selection

MIB selection is determining which SNMP MIBs to use and apply to, as well as which variables in each MIB are appropriate for, your network. This may, for example, be a full MIB (e.g., MIB-II is commonly used in its entirety), a subset of each MIB that is required for conformance to that MIB's specification (also known as a conformance subset of the MIB),[2] enterprise-specific MIBs (the parameters that are available from each vendor/network-element type), or you could define a subset of MIB parameters that apply to your network.

For example, a subset of performance monitoring parameters can be used from the interfaces MIB (RFC 2863): ifInOctets, ifInErrors, ifInUcastPkts, ifOutOctets, ifOutErrors, and ifOutUcastPkts. This set of six parameters is a common starting point for MIB parameters. These parameters can usually be measured on all interfaces for most network devices.

One can consider MIB variables falling into the following sets: a common set that pertains to network health and a set that is necessary to monitor and manage those things that the network needs to support, including:

  • Server, user device, and network parameters

  • Network parameters that are part of SLAs, policies, and network reconfiguration

7.6.7 Integration into OSS

When the network includes an interface to an OSS, the network management architecture should consider how management would be integrated with the OSS. The interface from network management to OSS is often termed the northbound interface because it is in the direction of service and business management (see Section 7.4). This northbound interface is typically CORBA or SNMP (Figure 7.18).

Click To expand
Figure 7.18: Integration of network management with OSS.

7.6.8 Internal Relationships

Internal relationships for the network management architecture are the interactions, dependencies, trade-offs, and constraints between network management mechanisms. It is important to understand these relationships—they are part of a complex, nonlinear system and these relationships define and describe the behavior of this architecture.

Interactions

Interactions within network management may include interactions between components of the management system; between the network management system and network devices; and between the network management system and the OSS.

If there are multiple network management systems or if the network management system is distributed or hierarchical, then there will be multiple components to the management system. The network architecture should include the potential locations for each component and/or management system, as well as the management data flows between components and/or management systems. The interactions here may be in the form of SNMP or CMIP/CMOT queries/responses, CORBA, HTTP, file transfers, or a proprietary protocol.

Part of network management is in each managed network device, in the form of management data (e.g., MIB variables) and software that allows access and transport of management data to and from the management system (e.g., SNMP agent software). Therefore, interactions between network management components (particularly monitoring devices) and managed network devices can also be considered here. We may choose to consider all of the managed network devices, depending on how many of them are expected in the network; however, we usually do not consider all managed devices in the network, for there can be quite a large number of them. As we discussed in Chapter 4, the devices that are most likely to be considered are those that interact with several users, such as servers and specialized equipment. Interactions here are likely to be in the form of SNMP or CMIP/CMOT queries/responses.

If your environment includes an OSS, there will likely be some degree of interactions between network management and the OSS for flow-through provisioning, service management, and inventory control. The network management architecture should note where the OSS would be located, which components of the network management system will interact with the OSS, and their locations in the network. Interactions here are likely to use CORBA but may use SNMP or HTTP (see the following subsection).

Dependencies

Dependencies within network management may include dependencies on capacity and reliability of the network for management data flows, dependencies on the amount of data storage available for management data, and dependencies on the OSS for the northbound interface requirement.

Network management may be dependent on the performance of the underlying network for support of management data flows. In its most basic sense, the network will need to provide sufficient capacity for the estimated amount of management data. This estimate can be derived using the information in Section 7.5. This is particularly important when network management is centralized, and all management data will be aggregated at the network management system interface. This may also be a dependency on IP services, discussed later in this section.

The amount of management data that can be stored is in part a function of how much storage will be available, so network management can be dependent on data storage availability.

Although network management may interface with an OSS, it may also be dependent on that OSS to determine the northbound interface. For example, some OSSs require CORBA for their interface, which will have to be supported by network management. This may also be considered a constraint on network management.

Trade-Offs

Trade-offs within network management may include trade-offs between in-band and out-of-band management and trade-offs between centralized, distributed, and hierarchical management. Trade-offs between in-band and out-of-band management include the following:

  • In-band management is cheaper and simpler to implement than out-of-band management, although when management data flows are in-band, they can be affected by the same problems that affect user traffic flows.

  • Out-of-band management is more expensive and complex to implement than in-band management (because it requires separate network connections); however, it can allow the management system to continue to monitor the network during most network events, even when such events disable the network. In addition, out-of-band management allows access to remote network devices for troubleshooting and configuration, saving the time and effort of having to be physically present at the remote location.

  • Out-of-band management, by definition, requires separate network connections. This may be a benefit in that security for the separate network can be focused on the requirements of management data flows, or it may be a liability in that additional security (with its associate expense and overhead) is required for this network.

  • When in-band and out-of-band management are combined, it will still have the expense and complexity of out-of-band management, as well as the additional security requirements; however, the combination allows (typically) higher-performance in-band management to be used for monitoring (which is the high-capacity portion of network management) yet still allows out-of-band management to be used at critical times (e.g., when the user data network [and in-band paths] is down).

Trade-offs between centralized, distributed, and hierarchical management include the following:

  • In centralized management, only one management system is needed (all management components, as well as other tools, are on one hardware platform), simplifying the architecture and reducing costs (depending on the choice of management system) over distributed or hierarchical management systems, which may have several separate components. However, centralized management can be a single point of failure, and all management data flows are aggregated at the management system's network interface, potentially causing congestion or failure. Distributed or hierarchical management can avoid central points of failure and reduce congestion points.

  • The degrees of distribution or hierarchy in management are a function of how complex and costly you are willing to allow the management system to become and how important it is to isolate management domains and provide redundant monitoring. Costs for distributed or hierarchical management will increase with the number of monitoring devices or management systems needed. However, if you are willing to accept high management costs, you can provide a fully redundant, highly flexible hierarchical management system for your network.

Constraints

Constraints include the northbound interface from network management to the OSS. This interface may be constrained by the interface requirement of the OSS. Since the OSS potentially ties together several service and business components, its interface requirements may be forced onto network management. CORBA is often required for this northbound interface.

7.6.9 External Relationships

External relationships are trade-offs, dependencies, and constraints between the network management architecture and each of the other component architectures (addressing/routing, performance, security, and any other component architectures you may develop).

Network management should be a part of all the other architectural components, for they will need some or all of the monitoring, control, and configuration capabilities that network management provides. As such, each of the other components will interact at some level with network management.

There are common external relationships between network management and each of the other component architectures, some of which are presented here.

Interactions between Network Management and Addressing/Routing

Network management depends on the addressing/routing architecture for the proper routing of management data flows through the network. If the management is in-band, the routing of management data flows should be handled in the same fashion as the user traffic flows and does not require any special treatment in the architecture. However, if the management is out-of-band, the routing of management data flows may need to be considered in the architecture.

Network management is often bounded by the network or networks that are under common management. A management domain is used to describe a set of networks under common management; an autonomous system is another term often used. Thus, the routing and addressing architecture may define the management domain for the network, setting the boundaries for network management.

If the management is out-of-band, the separate management network may require routing and addressing as part of the architecture.

Interactions between Network Management and Performance

Network management will interact with the performance architecture through the collection of network performance data for use to verify the proper operation of performance mechanisms. This may occur through a northbound interface (described earlier) to OSS or to a policy database for performance. Performance will also depend on network management to provide data on performance and function of the network.

A trade-off between network management and performance is in how much network resources (e.g., capacity) network management requires, as it may affect the ability to support various performance levels. This is particularly true when management is centralized, as management data flows in centralized management are aggregated at the management system's network interface.

Network management can depend on performance in two ways: First, if performance mechanisms support best-effort traffic (as determined in the flow specification), part of this best-effort traffic can be allocated to network management data flows; second, if a higher-priority service is desired for network management data flows, then network management will be dependent on performance mechanisms to provide the necessary support for such services. When network management data flows require high-priority service, network management may be dependent on performance mechanisms to function properly.

Interactions between Network Management and Security

Network management is dependent on some level of security in order to be used in most operational environments. This may be security at the protocol level (e.g., SNMP security) and/or securing access to network devices. If the management is out-of-band, the separate network that supports this management will need to be secured.

Network management may be constrained by security, if the security mechanisms used do not permit network management data or access across the security perimeter. This may also be considered a trade-off, when it is possible to reduce the level of security to support access or management data transport across the security perimeter.

For example, consider the use of POTS for out-of-band access. Such dial-in access is unacceptable to many organizations, unless extra security measures are taken on each access line (e.g., dial back, security keys).

[2]Conformance subsets of MIBs are usually listed at the end of each MIB's specification (RFC).


7.7 Conclusion

Although network management appears to be a simple function, it is actually a complex set of functions with interesting architectural features. In this chapter, we decomposed network management into monitoring, instrumentation, and management and explored how each of these can be achieved within the network management architecture.

The essence of the network management architecture is in understanding what you want to monitor and manage, determining where you want to locate each network management function, and managing the flows of network management traffic. Depending on the characteristics of the network you are developing, you have a wide range of architectural solutions, from a simple single-platform system with preconfigured monitoring and management capabilities to a distributed, hierarchical system in which you determine and configure its monitoring and management capabilities.

Based on the information in this chapter, you have the flexibility to create a network management architecture tailored to the requirements of your customer.


7.8 Exercises

  1. What are the layers of network management? Give an example of management at each layer (what is managed, how is it managed).

  2. What are the differences between monitoring for events and monitoring for trend analysis and planning? Give an example of each type for the following:

    1. Monitoring the capacity of an OC-3c WAN link

    2. Monitoring the utilization of an IP router

  3. Which of the following are end-to-end characteristics? Per-link/per-network/per-element characteristics?

    1. Round-trip delay between a network management device and a computing server

    2. Percentage of utilization of the buffers in an IP router

    3. Maximum throughput between two devices (client and server) using a client-server application

    4. Bit error rate (BER) of a DS3 link

  4. For each of the SNMP commands get, get-next, and set, describe what each command does and give an example of how it is used.

  5. How much storage capacity is required for the network management configuration shown in Figure 7.19 (p. 328)?

    Click To expand
    Figure 7.19: Devices for storage capacity problem.

    Exercises 6 through 10 refer to Figure 7.20 (p. 328).

    Click To expand
    Figure 7.20: Diagram for Exercises 6 through 10.

  6. This enterprise network currently has a network management system at the corporate network operations center (NOC), located in Minneapolis, which monitors only the 13 corporate routers. Develop a network management architecture that will allow monitoring of the routers, all 190 user devices, and dialup routers, keeping the management traffic local to each area (Los Angeles, Minneapolis, and Washington, DC).

  7. How much management data would be generated in a centralized management approach, assuming data collection of nine SNMP counters on all routers and Internet Control Message Protocol ping polling of all devices (network and user), with a polling interval of 5 minutes? Each SNMP counter and ping generates 64 bytes of data.

  8. Add devices for managing each of the remote sites (outside of the Minneapolis area) out-of-band from the corporate NOC.

  9. How does the addition of out-of-band management between the corporate NOC and remote sites potentially affect the security of the network?

  10. Recommend two ways that the management data collected via SNMP counters from each of the routers could be verified.


Chapter 8: Performance Architecture

The performance architecture describes how user, application, device, and (existing) network requirements for performance (capacity, delay, and reliability, maintainability, and availability [RMA]) will be met within the planned network. Developing requirements for performance is a key part of the analysis process, and this component architecture is where they are supported.

The performance architecture is the newest of the component architectures and is rapidly evolving to include many new mechanisms to achieve network performance. Furthermore, as you will see in this chapter, the success of this architecture is highly dependent on the other component architectures.

8.1 Objectives

In this chapter, you will learn about what performance means in a network, including descriptions of mechanisms to achieve performance, how to determine the relationships both between these mechanisms and between performance and the other architectural components, and development of the performance architecture. We will also develop goals for performance that will guide the development of this architecture.


8.2 Preparation

To be able to understand and apply the concepts in this chapter, you should be familiar with the basic concepts and mechanisms of performance. The basic concepts of performance were discussed in Chapters 1, 2, and 3, and the coupling of performance to traffic flows in Chapter 4 of this book. In addition, concepts of network architecture were presented in Chapter 5.

If you need additional information on network performance and performance mechanisms, some recommended sources include:

  • Internet QoS: Architectures and Mechanisms for Quality of Service, by Zheng Wang, Morgan Kaufmann Publishers, March 2001

  • Designing Quality of Service Solutions for the Enterprise, by Eric D. Siegel, John Wiley & Sons, October 1999

  • High-Speed Networking: A Systematic Approach to High-Bandwidth Low-Latency Communication, by James Sterbenz and Joseph Touch, John Wiley & Sons, April 2001

  • Queuing Systems Theory, volume 1, by Leonard Kleinrock, John Wiley & Sons, January 1975

  • Requests for comments (RFCs) from the Differentiated Services (DiffServ) Working Group of the Internet Engineering Task Force, RFC 2474 and 2475 in particular; available at www.ietf.org


8.3 Background

Performance is the set of levels for capacity, delay, and RMA in a network. It is usually desirable to optimize these levels, either for all (user, application, and device) traffic flows in the network or for one or more sets of traffic flows, based on groups of users, applications, and/or devices.

In support of performance in the network, a performance architecture is the set of performance mechanisms to configure, operate, manage, provision, and account for resources in the network that support traffic flows. The performance architecture shows where these mechanisms are applied within the network, as well as the sets of internal and external relationships between this and other component architectures. In this chapter, we will learn about network resources and about mechanisms to control and manage them.

An important part of developing this architecture is determining the performance goals for your network. For example, performance may be applied to:

  • Improve the overall performance of the network (e.g., to improve response times and throughput to all users, regardless of where they are and what they are doing)

  • Support a particular group or groups of users or applications, may be new or planned applications

  • Control resource allocation for accounting, billing, and/or management purposes

We will discuss developing goals for performance later in the next section. In general, performance consists of one or more of the following: controlling traffic inputs to the network (admission and rate controls); adjusting the baseline performance of the network (traffic or capacity engineering); controlling all or part of the network for delivery of specific services (prioritizing, scheduling, and conditioning traffic flows); and implementing a feedback loop to users, applications, devices, and management to modify controls as necessary. Figure 8.1 shows these general mechanisms.

Click To expand
Figure 8.1: General mechanisms for performance.


8.4 Developing Goals for Performance

For each component architecture, understanding why that function is needed for that particular network is important; this is especially important for the performance architecture. The process of developing goals for this (or any other) component architecture begins during the requirements analysis process and is further refined during the architecture process. Therefore, the requirements and flow specifications and maps provide important input to this process.

Although performance is always desirable, we need to ensure that the performance mechanisms incorporated into the architecture are necessary and sufficient to achieve the performance goals for that network. Therefore, toward developing this architecture, we should answer the following questions:

  1. Are performance mechanisms necessary for this network?

  2. What are we trying to solve, add, or differentiate by adding performance mechanisms to this network?

  3. Are performance mechanisms sufficient for this network?

In determining whether performance mechanisms are necessary for a network, we should already have the information needed to make a decision from the requirements and flow analyses. Part of the purpose of determining the necessity of performance mechanisms is to avoid implementing such mechanisms just because they are interesting or new. For example, it may be tempting to implement quality-of-service (QoS) mechanisms in a network, even when there are no clear goals or problems to solve.

When performance mechanisms are indicated, start simple and work toward a more complex architecture when warranted. Simplicity may be achieved in this architecture by implementing performance mechanisms only in selected areas of the network (e.g., at the access or distribution [server] networks), by using only one or a few mechanisms, or by selecting only those mechanisms that are easy to implement, operate, and maintain.

There should be information in the requirements and flow analyses that can help you determine the need for performance mechanisms in a network. Some requirements include:

  • Clearly different sets of network performance requirements, per user, group, application, device, and/or flow

  • Requirements to bill and account for network service

When you plan to implement performance mechanisms in a network, you should also determine whether your customer is willing to pay the costs for such mechanisms. For example, does your customer have a network staff that is capable of configuring, operating, and maintaining QoS, SLAs, and policies? If not, is the customer willing to pay the cost to acquire such staff or outsource performance (and some portion of network management)? Performance is not a capability that is implemented once and then forgotten; it requires continual support. If your customer is not willing to provide that support, it is better not to implement such mechanisms.

Experience has shown that when performance mechanisms are implemented and not supported, maintained, or kept current, performance in the network can actually degrade to a point at which it would be better not to have any performance mechanisms. Therefore, determining the requirements for performance and the willingness of your customer to support performance is critical to developing this architecture.

Having established a need for performance in the network, you should also determine what problems your customer is trying to solve. This may be clearly stated in the problem definition or developed as part of the requirements analysis, or you may need to probe further to answer this question. Some common problems that are addressed by the performance architecture include:

  • Improving the overall performance of a network

  • Improving the performance to select users, applications, and/or devices

  • Changing the network from a cost center to profitability

  • Merging multiple traffic types over a common network infrastructure

  • Differentiating (and possibly charging) customers for multiple levels of service

Improving the overall performance of a network is consistent with the network having single-tier performance (determined during the requirements analysis). When all users, applications, and/or devices in a network require a similar level of performance, your goal may be to improve performance for everyone.

When sets of users, applications, and/or devices require greater performance than others on the same network, performance mechanisms are required to deliver multiple performance levels. Such networks have multitier performance.

When you are attempting to charge customers for service and possibly to generate revenue for network service, performance mechanisms are needed to provide the contractual framework between subscribers and provider, as well as to deliver multiple performance (and charging) levels.

Performance mechanisms are also needed when a customer wants to merge multiple traffic flow types. This is common when multiple networks are being consolidated. For example, when building a new data network, your customer may want to (eventually) migrate voice and video services onto that network, eliminating the existing separate voice and video networks. Performance mechanisms are needed to be able to identify these multiple traffic flow types and provision the required network resources to support each flow.

Finally, having established the need for performance in the network, and determining what problems will be solved by implementing performance mechanisms, you should then determine whether these performance mechanisms are sufficient for that network. Will they completely solve the customer's problems, or are they only a partial solution? If they are a partial solution, are there other mechanisms that are available or will be available within your project timeframe? You may plan to implement basic performance mechanisms early in the project and upgrade or add to those mechanisms at various stages in the project.


8.5 Performance Mechanisms

As presented Chapter 7, performance mechanisms discussed here include QoS, resource control (prioritization, traffic management, scheduling, and queuing), service-level agreements (SLAs), and policies. These mechanisms incorporate the general mechanisms shown in the previous section (see Figure 8.1).

Subsets of these mechanisms are usually used together to form a comprehensive approach to providing single-tier and multitier performance in a network. These mechanisms provide the means to identify traffic flow types; measure their temporal characteristics; and take various actions to improve performance for individual flows, groups of flows, or all flows in the network.

8.5.1 Quality of Service

QoS is determining, setting, and acting on priority levels for traffic flows. QoS is usually associated with IP but is used here to define a class of mechanisms that are used at multiple layers in the network to provision and apply priority levels. This class includes IP QoS (including multiprotocol label switching [MPLS]), type of service (ToS), ATM class of service (CoS), and frame relay committed information rate (CIR). In this section, we will focus on IP QoS.

For IP-based traffic, there are two standard types of QoS: differentiated services (DiffServ, or DS) and integrated services (IntServ, or IS), intended to support two views of network service. DiffServ approaches QoS from the perspective of aggregating traffic flows on a per-hop basis based on traffic behavior, and IntServ approaches QoS from the perspective of supporting traffic flows on an individual end-to-end basis.

In DiffServ, IP packets are marked in the ToS byte for IPv4 or in the traffic class byte in IPv6 so that they will receive the corresponding performance at each network device (or hop). DiffServ defines a set of values (termed differentiated services code points [DSCPs]) for classes of traffic flows to be used by resource control mechanisms. An important concept of DiffServ is that it applies to aggregates of traffic flows (e.g., composite flows), not individual traffic flows.

The main reason for this is for scalability (particularly across the Internet, but could also be applied in a large enterprise environment). If in a network architecture and design all flows requiring priority service were treated individually, one trade-off in the network is the amounts of resources (e.g., memory in network devices) required to store and maintain state information for each individual flow across the network. This resource requirement grows geometrically with the network and therefore does not scale well. By aggregating flows into traffic classes, storing and maintaining state information becomes more tenable. State information, or state, is information about the configuration and status of flows or connections. Examples include addresses (IP or MAC-layer), time (duration of flow/connection, idle time), and temporal characteristics (data rates, packet losses). A detailed discussion of state information can be found in Chapter 10.

There are three traffic classes for DiffServ: best effort, assured forwarding (AF), and expedited forwarding (EF). AF and EF are the preferred traffic classes and are based on the types of performance they require. EF is usually targeted toward traffic that has delay requirements (e.g., real-time or interactive), whereas AF can be used for traffic with both delay and capacity requirements (e.g., multimedia or tele*services).

There are times, however, when a traffic flow needs to be treated individually. IntServ defines values and mechanisms for allocating resources to flows across the end-to-end path of the flow. IntServ is closely tied to the flow nature of a network by placing importance on supporting a flow at every network device in the end-to-end path of that flow. Recall from our discussion of flow analysis that end-to-end paths are defined by you and will vary depending on what you are trying to accomplish. In defining where end-to-end applies for particular flows (e.g., flows with guaranteed requirements), you are determining where mechanisms such as IntServ could be applied.

As mentioned with DiffServ, however, the advantages of IntServ come at a price. IntServ requires support on the network devices across which the flow travels, and it requires resources (e.g., memory, processing, bandwidth) for each flow. Support across multiple networks implies coordination of service between those networks. And requiring resources for each flow means that it will not scale well in areas where flows converge (e.g., the core area of a network).

IntServ also requires a mechanism to communicate flow requirements, as well as the setup and teardown of resource allocations, across network devices in the end-to-end path of a flow. Such signaling is usually provided by the Resource Reservation Protocol (RSVP). Other signaling mechanisms, such as with MPLS, are also being developed for this purpose.

RSVP is used by network devices (including user devices) to request specific QoS levels from network devices in the end-to-end path of a traffic flow. Successful RSVP requests usually result in resources being reserved at each network device along this end-to-end path, along with state information about the requested service.

Thus, a mechanism such as this is best applied in an environment where the network administrator has control of the end-to-end path of the flow, such as within an enterprise environment. Although IntServ is often shunned because of its complexity and scalability issues, it can be used, but it should be used only when there is a strong case for it (from the requirements and flow specifications), and then with an understanding of what will be required in terms of network and personnel resources to implement and maintain it.

A comparison of some of the functions and features of DiffServ and IntServ is presented in Figure 8.2.

Function/Feature | Differentiated Services (DiffServ) | Integrated Services (IntServ)
Scalability | Scalable to Large Enterprise of Service-Provider Networks | Limited to Small or Medium-Size Enterprise Networks
Granularity of Control | Traffic Aggregated into Classes | Per-Flow or Groups of Flows
Scope of Control | Per Network Device (Per-Hop) | All Network Devices in End-to-End Path of Flow

Figure 8.2: Comparison of DiffServ and IntServ.

DiffServ and IntServ can be applied individually or together within a network, and it is possible to combine these mechanisms in a variety of ways. For example, DiffServ may be applied across the entire network by itself, or both may be applied in different areas of the network. In addition, both mechanisms may be applied to the same areas of the network, targeted at different types of flows. In this case DiffServ is first applied to the network, and IntServ is then overlaid onto it.

If we consider the access/distribution/core architectural model (presented in Chapter 5) in the context of IP QoS, we can begin to see where these mechanisms might apply. The access portion of the network is where most flows are sourced and sinked, and as such, this is where they can be (most easily) supported individually. The core of the network is where bulk transport of flows occurs, where it would make the most sense to aggregate them. Thus, one way to look at prioritizing flows is presented in Figure 8.3, where flow aggregation via DiffServ is applied at the core portion, perflow service via IntServ is applied at the access portion, and some translation occurs between the two at the boundary between access and core, possibly at the distribution network.

Click To expand
Figure 8.3: Where DiffServ and IntServ apply in the access/distribution/core model.

In Figure 8.3, IntServ is applied as an end-to-end mechanism, where the end points are defined between devices within each access (and possibly its serving distribution) area. Therefore, it is targeted toward those flows that remain within an access network or are sourced/sinked at the distribution network. For example, this would apply for client-server flows where the servers are located at the distribution network.

For flows that cross the core network, their performance would change from IntServ at the access and distribution networks to DiffServ at the core network, and individual state would be lost as a trade-off for scalability. However, flows that remain in the access or distribution networks would still get the full benefits of IntServ. And, importantly, IntServ could be used to signal the core network for resources for a traffic class.

It is also possible to apply both IntServ and DiffServ so that they work concurrently across the entire network. In a case like this (shown as the end-to-end flows in Figure 8.3), IntServ would be used only for a relatively small percentage of flows and would be used end-to-end. DiffServ would be used for other prioritized flows and could be aggregated at either the access or the distribution network.

DiffServ and IntServ are used to apply prioritization, scheduling, and resource control to traffic flows. How these mechanisms work is described in the following section.

8.5.2 Prioritization, Traffic Management, Scheduling, and Queuing

Prioritization, traffic management, scheduling, and queuing are at the heart of providing performance in a network. A performance architecture may include one or more of these mechanisms, in conjunction with QoS, SLAs, and policies, to provide performance to its users, applications, devices, and traffic flows.

These mechanisms are usually implemented in network devices such as routers and switches but can also be applied to the network as stand-alone hardware, such as in vendor-specific admission control and traffic management devices.

Prioritization

Prioritization is the process of determining which users, applications, devices, flows, and connections get service ahead of others or get a higher level of service. Prioritization is necessary, for there will be competition between traffic flows for network resources. With a limited amount of resources available in any network, prioritization determines who gets resources first and how much is allocated.

Prioritization begins during the requirements and flow analyses. Priority levels for users, applications, and devices should be determined as part of the requirements analysis, and priority levels for traffic flows determined during the flow analysis process. For example, you may recall that in Chapter 4 we discussed how to prioritize flows based on the various parameters, such as the numbers of users supported and performance requirements.

For a performance architecture, there are two high-level views of performance: single-tier performance, in which capacity, delay, and RMA are optimized for all traffic flows, and multitier performance, in which capacity, delay, and RMA are optimized for one or more groups of traffic flows, based on groups of users, applications, and/or devices. Either or both of these views can be taken for a network architecture. As with our approach to DiffServ and IntServ, single-tier performance may apply across the entire network, with multitier performance in select areas or as an addition to single-tier performance.

These two views of performance imply that there may be multiple levels (tiers) of performance required by different groups of traffic flows. Whenever there are multiple levels of performance requirements in a network (and thus multiple groups of traffic flows), there will be a need to prioritize these traffic flows. Prioritization is ranking (determining a priority level) based on importance and urgency. Ranking may be applied to users, applications, devices, or their traffic flows. A rank or priority level indicates the importance and/or urgency of that user, application, device, or flow, relative to other users, applications, devices, or flows in that network. Such priority levels are often determined during the requirements and flow analyses.

The most basic or degenerate case of prioritization is when every user, application, device, or flow has the same priority level. Such is the case in best-effort networks. When a user, application, device, flow, or groups of these require performance greater than the general case, they will have higher priority levels. In addition, an individual or group at the same priority level as other individuals or groups may change its priority level due to the urgency of its work.

For example, most users on a network have a common set of applications and devices. They will often use a similar type of desktop or laptop computer, with a standard type of network interface. They will likely use email, Web, word processing, and other common applications. Such users may constitute a group of single-tier performance users, all with a single priority level. For some networks, this is as far as prioritization gets, and the performance architecture focuses on optimizing performance for everyone in this group. In some cases, however, even a single, single-tier performance group may have multiple priority levels. With the aforementioned example, priority levels can be used to allow preference to individuals who have not used the network for some time or who are willing to pay a premium for preferred access.

Priority levels may be based on the type of protocol (e.g., TCP versus User Datagram Protocol), service, or port number; by IP or MAC-layer address; or by other information embedded within the traffic. This information can be maintained in databases and coupled with policies and SLAs (discussed later in this chapter) as part of the performance architecture.

Priority levels are used by network devices to help determine whether traffic flows will be allowed on the network (admission control), to schedule traffic flows onto the network, and to condition flows throughout the network.

Traffic Management

Priority levels determine the relative importance and urgency of traffic flows and how each traffic flow will be handled within the network. Traffic management consists of admission control and traffic conditioning. Admission control is the ability to refuse access to network resources. Traffic conditioning is a set of mechanisms that modify (increase or decrease) performance to traffic flows, as a precursor to scheduling.

Admission control uses priority levels to change the behavior of network access. In a best-effort network without admission control, access to the network is democratic in that all traffic flows have a (more or less) equal chance to get network resources. With admission control, however, access is permitted, denied, or sometimes delayed based on the relative priority of that traffic.

An example of this is assigning a higher priority to real-time traffic flows, such as voice and video. In this example, voice and video traffic flows are given access before other traffic flows. When network resources dedicated to these flows are fully utilized, further flows are refused (blocked). Admission control is most often applied at access areas.

To understand traffic conditioning functions, we will follow traffic flows across a network device that implements traffic conditioning. As traffic flows enter a network device, there must be a mechanism to identify flows and distinguish between flows. Classification is the ability to identify traffic flows. The classifier will look at various parts of the IP packet, such as source and destination addresses, port numbers, or protocol types. In addition, the classifier may look deeper into a packet for the necessary information. For example, voice over IP (VoIP) signaling flows may be determined by looking for Session Initiation Protocol (SIP) identifiers (RFC 3261) within the packets. Upon identifying traffic flows that are important for that network, packets within these flows may be marked, or tagged with a priority level. Examples of marking included tagging packets with DSCPs for best-effort, AF, and EF priority levels.

Once traffic flows have been classified, they may be metered to determine their performance levels. Metering is measuring the temporal performance characteristics of a traffic flow, including traffic rates and burst sizes. Performance characteristics are measured periodically and compared with expected performance boundaries, which can be from SLAs and/or policies. Metering is most often a capability provided in network devices (e.g., routers and switches) as part of their performance implementation but can also be applied as a separate network device (e.g., some network management devices can provide metering support).

For example, a traffic flow may be metered over a period of 1 second. Each second, the peak data rate for that flow is compared to a capacity boundary of 1.5 Mb/s, which was input into the network device from an SLA developed for that traffic flow.

Metering a traffic flow can determine whether a flow is within performance boundaries (Figure 8.4). Conforming traffic is within performance boundaries; nonconforming traffic is outside of performance boundaries. Typically, no action is taken on conforming traffic. Conforming traffic is forwarded to the appropriate output queue (as determined by its priority level) and scheduled for transmission onto the network.

Click To expand
Figure 8.4: Illustration of traffic metering at a network device.

When traffic is nonconforming, however (indicating that it is exceeding the specifications of an SLA), it is subject to shaping or dropping. Shaping is delaying traffic to change a performance characteristic, and dropping is discarding traffic. Nonconforming traffic may also be marked, with no other action taken. This is done so that network devices upstream (those receiving this traffic flow) can choose to shape or drop this traffic if necessary.

To shape nonconforming traffic, it may be sent to a shaper queue where delay is added before it is transmitted onto the network. By delaying traffic, a shaper queue changes the performance of that traffic flow. Consider an SLA for a traffic flow that specifies a peak rate of 1.5 Mb/s (Mb/s is shown as Mbits/second in the following discussion for consistency in units, in practice, rate is usually shown as Kb/s, Mb/s, or Gb/s). A meter is measuring that traffic flow and calculates a rate of

(200 packets/second) × (1500 byte packets) × (8 bits/byte) = 2.4 Mbits/second

This is compared with the SLA specification (1.5 Mbits/second) and found to be nonconforming. Subsequent packets are then forwarded to a shaper queue, where they are delayed by an average of 10 ms. As a result, only 100 packets can be transmitted per second, and the rate of that traffic flow becomes

(100 packets/second) × (1500 byte packets) × (8 bits/byte) = 1.2 Mbits/second

Shaping will continue either for a specified period or until the traffic flow is again conforming.

The most serious action that can be taken on traffic is dropping, or discarding, packets. This is done when a traffic flow is seriously exceeding its performance boundary or when the network device is congested to the point at which dropping packets is necessary. Traffic conditioning functions are shown in Figure 8.5.

Click To expand
Figure 8.5: Traffic conditioning functions.

Scheduling

Once traffic has been prioritized and conditioned, it is forwarded to one or more output queues for transmission onto the network. Scheduling is the mechanism that determines the order in which traffic is processed for transmission. Scheduling uses priority levels to determine which traffic flows get processed first and most often.

Scheduling is applied at network devices throughout a network. In most network devices, such as switches and routers, scheduling is provided through network management or as part of the QoS implementation in that device.

Scheduling may be proprietary (enterprise specific) or standards based. Some commonly used standard scheduling algorithms include weighted fair queuing and class-based queuing. These algorithms provide some degree of fairness in queuing while allowing relative priority levels (weights).

The combination of QoS, prioritization, traffic management, and scheduling provides a comprehensive set of mechanisms that can be applied across a network to achieve various performance levels for traffic flows (Figure 8.6). As we will see, these mechanisms are closely tied to SLAs and policies, which are discussed in Section 8.5.3.

Click To expand
Figure 8.6: Performance mechanisms act on network devices.

Queuing

We complete this section with a discussion of queuing. Queuing is storing IP packets (this can also be applied to Ethernet frames or ATM cells, but for the purposes of this discussion, we will limit it to IP packets) within a network device while they wait for processing. There may be several locations where packets are stored (queues) within a network device for each type of processing that the device is performing on each packet (e.g., holding packets received from the network, processing for QoS, holding packets for transmission onto the network).

A number of queuing mechanisms are available in network devices. Each mechanism is developed to achieve a particular objective in processing packets. For example, queue mechanisms may treat all packets the same way, may randomly select packets for processing, or may favor particular packets. In this chapter, we will briefly consider the following queuing mechanisms:

  • First In First Out (FIFO)

  • Class-based queuing (CBQ)

  • Weighted fair queuing (WFQ)

  • Random early detect (RED)

  • Weighted RED (WRED)

FIFO queuing is arguably the simplest queuing mechanism available. In FIFO, queuing packets are stored in a single queue. For an output FIFO queue, packets are transmitted onto the network in the order in which they were received (at the input queue).

In CBQ, multiple queues with differing priorities are maintained. Priority levels are configurable in the network device and indicate the performance levels required for each traffic type. Packets of each priority level are placed in their respective queues. Higher priority queues are processed before lower priority queues so higher priority traffic receives more network resources and thus has greater performance.

Like CBQ, WFQ assigns priorities (weights) to queues. Typically, with this mechanism, high-priority traffic flows are processed first and lower-priority traffic flows share the remaining resources.

Generally, when a queue becomes full (e.g., during periods of congestion), packets are dropped either from the beginning of the queue (head) or at the end of the queue (tail). In either case the dropping of these packets is likely to be unfair to one or a few traffic flows. As a result, RED was developed to randomize the packet-dropping process across a queue. In addition, RED will drop packets early (before the queue is actually full) to force traffic flows (i.e., TCP flows) to adjust by reducing their transmission rate.

WRED operates in the same fashion as RED but supports multiple priority levels (one for each queue) for dropping packets.

8.5.3 Service-Level Agreements

SLAs are (typically) formal contracts between a provider and a user that define the terms of the provider's responsibility to the user and the type and extent of accountability if those responsibilities are not met. Although SLAs have traditionally been contracts between various service providers (e.g., ISPs) and their customers, this concept can also be applied to the enterprise environment. In fact, the notion of customer and provider is becoming more common in enterprise networks as they evolve from treating networks as just infrastructure (cost-center approach) to treating them as centers for providing services to their customers (users).

There are two common ways to apply SLAs within a network. First, an SLA can be an agreement between network management/administration and their customers (the network users). Second, an SLA can be used to define the levels of services required from third-party service providers (e.g., cable plant providers, various service providers) for the network.

SLA performance elements may be as simple as a data rate (minimum, peak) and burst tolerance (size, duration) and can be separated into upstream (in the direction from the destination to the source) and downstream (in the direction from the source to the destination). Figure 8.7 shows upstream and downstream for a traffic flow, along with the data sources and sinks.

Click To expand
Figure 8.7: Upstream and downstream directions.

Although these terms can apply for any flow, they are most commonly used in service-provider networks. In such networks, the sources of most traffic flows are servers on the Internet and most destinations are subscriber PCs at the service provider's access networks. For this case, downstream is from these servers (i.e., from the Internet) to the subscriber's PC and upstream is from the PC to the Internet. For example, Web pages downloaded from the Internet to a subscriber's PC generate TCP traffic downstream from a Web server to the subscriber PC, and TCP acknowledgments upstream from the subscriber PC to the Web server (Figure 8.8).

Click To expand
Figure 8.8: Upstream and downstream directions for Internet Web traffic.

SLAs can include delay and RMA metrics for more complete provisioning of service. An example of an enterprise SLA is shown in Figure 8.9.

Network Service Description for My Enterprise
Service Levels: | Capacity Performance | Delay Performance | Reliability Performance
Basic Service | As Available (Best Effort) | As Available (Best Effort) | As Available (Best Effort)
Silver Service | 1.5 Mb/s (Bidirectional) | As Available (Best Effort) | As Available (Best Effort)
Gold Service | 10 Mb/s (Bidirectional) (Burst to 100 Mb/s) | Max 100-ms Round-Trip (Between Specified Points) | As Available (Best Effort)
Platinum Service | 100/10 Mb/s Up/Down (Burst to 1 Gb/s) | Max 40-ms Round-Trip (Between Specified Points) | 99.999% Uptime (User-Server)

Figure 8.9: Example of enterprise SLA.

This SLA specifies capacity, delay, and RMA levels for various types of users and their applications and devices. A basic, or best-effort, service level is shown, in which all performance characteristics are best effort. This service level is the default and would normally be provided to any user free of charge.

The other service levels (silver, gold, and platinum) specify increasing levels of capacity, delay, and RMA performance. Users who subscribe to these performance levels would likely be charged for usage. This may take the form of an internal charge within each organization, an allocation of resources, or both. For example, each valid subscriber to the platinum service (only a certain type of user may be allowed to use this service, based on the user's type of work and needs) may be allocated N hours per month. Usage exceeding N hours per month would result in a charge to that user's organization.

Figure 8.9 is an example of a fairly complex SLA and is used to illustrate how an SLA may be structured. In practice, SLAs are usually simpler, with two to three service levels. Depending on the requirements of an organization, however, an SLA can be more complex than the provided example.

An SLA is typically a contract between users and service providers about the types of services being provided. In this sense, an SLA forms a feedback loop between users and the provider. The service provider has the responsibility of monitoring and managing services to ensure that the users are getting what they are expecting (and possibly paying for) and that users are made aware of what is available to them.

Figure 8.10 shows that, when SLAs are added to the performance architecture, they provide a means for communicating between users, staff, and management about performance needs and services.

Click To expand
Figure 8.10: Performance mechanisms with SLAs added.

For SLAs to be effective as feedback loops, they need to operate in conjunction with performance monitoring and trouble reporting/ticketing, as part of the performance or network management architectures.

8.5.4 Policies

Policies are formal or informal sets of high-level statements and rules about how network resources (and, therefore, performance) are to be allocated among users. They are used to create and manage one or more performance objectives. Policies complete the framework of performance for a network by coupling the high-level (e.g., management) view of how the network should perform with mechanisms to implement performance at the network devices (QoS) and feedback loops with users (SLAs) (Figure 8.11).

Click To expand
Figure 8.11: Performance mechanisms with policies added.

Policies may describe which network, computing, storage, or other resources are available to users, when resources are available, or which users are permitted to access certain resources. In this sense, these policies are similar to policies for security or routing.

Policy information is often implemented, stored, and managed in policy databases kept on the network. Policy information is passed between databases and network devices using common open policy services and Lightweight Directory Access Protocol (LDAP).


8.6 Architectural Considerations

In developing our performance architecture, we need to evaluate potential performance mechanisms and determine where they may apply within the network, as well as the sets of internal and external relationships for this component architecture.

8.6.1 Evaluation of Performance Mechanisms

At this point, we should have requirements, goals, type of environment, and architectural model(s) and are ready to evaluate potential performance mechanisms. When evaluating performance mechanisms, start simple (e.g., DiffServ QoS) and work toward more complex solutions only when necessary.

Where a performance mechanism will apply in a given network will depend primarily on where performance requirements are located throughout the network, based on the results of the requirements and flow analyses. In addition to the requirements and flow analyses, we can use any architectural goals that have been developed, as well as the architectural models presented in Chapter 5.

Recall that the access/distribution/core architectural model separates a network based on function, where the core network supports the bulk transport of traffic flows, distribution networks support flows to and from servers and aggregate traffic flows from access networks, and access networks are where most traffic flows are sourced and sinked. This functional separation of a network can be applied when evaluating performance mechanisms.

For example, performance mechanisms that operate on individual traffic flows, such as admission control and signaling for resources, IntServ, and ATM QoS, should be considered where traffic flows are more likely to be individual (e.g., before they are aggregated), such as at access networks. Performance mechanisms that operate on aggregates of traffic flows, such as DiffServ, CBQ, WFQ RED/WRED, and MPLS, should be considered where traffic flows are more likely to be aggregated, such as at distribution and/or core networks or at interfaces to external networks.

An example of where performance mechanisms may generally be applied is presented in Figure 8.12. Note that these are to be used as general guidelines. Depending on the network, any performance mechanism may be applied at any area of a network.

Click To expand
Figure 8.12: General applications of performance mechanisms.

Along with determining the regions of the network where each performance mechanism will apply, we also need to consider which devices will implement each mechanism. Examples include DiffServ edge devices, where traffic flows are classified and marked with DSCPs, and policy decision points (PDPs), which are servers where policies are configured and maintained. Policies are implemented at policy enforcement points (PEPs), which include network devices that are configured for performance (e.g., through QoS).

8.6.2 Internal Relationships

Interactions within the performance architecture include trade-offs between end-to-end and per-hop prioritization, scheduling, and conditioning of traffic flows, admission control, and whether flows are treated individually or aggregated into groups. These interactions are closely coupled to the use of DiffServ and IntServ within the network.

When policies, SLAs, and DiffServ are chosen, part of this component architecture describes the placement of databases for SLA and policy information, including PDPs, PEPs, and DiffServ edge devices.

8.6.3 External Relationships

External relationships are trade-offs, dependencies, and constraints between the performance architecture and each of the other component architectures (addressing/ routing, network management, security, and any other component architectures you may develop).

There are common external relationships between performance and each of the other component architectures, some of which are presented in the following subsections.

Interactions between Performance and Addressing/Routing

Performance can be closely coupled with routing through mechanisms such as MPLS, DiffServ and IntServ, and RSVP. However, when routing protocol simplicity is a high priority, performance may be decoupled from forwarding.

Interactions between Performance and Network Management

Performance depends on network management to configure, monitor, manage, verify, and bill for performance levels throughout the network. Network management helps to couple QoS, SLAs, and policies by providing common communications paths and protocols for performance information. In addition, network management can tie performance management to the customer's operations support system (OSS).

SLAs need to be coupled with network management for performance monitoring and trouble reporting/ticketing. This provides the feedback loop necessary between performance and network management, users, and management/staff.

Interactions between Performance and Security

As we will see in Chapter 9, security mechanisms are often intrusive, intercepting, inspecting, and controlling network access and traffic. Such actions require network resources and processing, increasing network delay. As security is increased by adding more mechanisms (and mechanisms that are more intrusive) to the network, performance is decreased. Whereas capacity can sometimes be increased to offset a decrease in performance caused by security, increased delay is difficult to mitigate.

When performance is high priority, particularly when there is a need to provision end-to-end performance between select users, applications, or devices, performance mechanisms may preclude the use of intrusive security mechanisms in those areas of the network.

When security mechanisms interrupt or terminate and regenerate traffic flows, they seriously affect the ability to provide end-to-end performance across the security interface. As a result, security constrains performance to operate within a security perimeter (Figure 8.13). These security perimeters, or security zones or cells, can be configured in different ways. This will be discussed further in Chapter 9.

Click To expand
Figure 8.13: Performance is constrained by security.


8.7 Conclusion

In this chapter, we learned about developing the performance architecture for a network. The performance architecture consists of determining which performance mechanisms (QoS, prioritization, scheduling, traffic conditioning, SLAs, and policies) apply to a particular network, where each mechanism may apply, and the relationships within the performance architecture and between performance and other component architectures.

The performance architecture is the first of the component architectures that we will be examining. As we go through each component architecture, the reference architecture (consisting of all the external relationships) for the network will emerge.


8.8 Exercises

For Exercises 1 through 6, refer to the performance requirements listed here.

  • Requirement 1: Two clearly different sets of network performance requirements— one high RMA and the other low RMA (for that network)

  • Requirement 2: A requirement to bill subscribers for network service and to provide accounting of subscriber billing information

  • Requirement 3: Combining a customer's voice and data traffic over a common network

  1. For each performance requirement listed, explain why performance mechanisms are needed to support the requirement.

  2. DiffServ and IntServ are two approaches to providing QoS in IP networks and are designed to support performance from different perspectives. For the requirements listed, which would you recommend: DiffServ, IntServ, both, or neither? Give reasons for your choices.

  3. Which of the requirements indicates single-tier performance? Multitier performance?

  4. Figure 8.5 shows the traffic conditioning functions: classification, marking, metering, shaping, and dropping. For Requirement 3 (combining voice and data traffic), outline how the process of traffic conditioning, using these five functions with DiffServ, would be applied to this requirement. Assign a DSCP to each traffic type.

  5. Combining Requirements 2 and 3, write an SLA for this network and include sample pricing for Requirement 2. Use the following performance requirements:

    1. Voice traffic must have an availability (RMA) of 99.999% (excluding scheduled maintenance times), measured everywhere in the network.

    2. Data traffic must have an availability (RMA) of 99.99% (excluding scheduled maintenance times), measured between user devices and servers.

  6. A performance architecture consists of QoS, SLA, and policy mechanisms, applied at network devices and servers, to support performance within the network (Figure 8.14). Given that there will be a policy and SLA database server and IP routers and Fast Ethernet switches with DiffServ QoS, outline how QoS, SLAs, and policies could be implemented to support the two sets of performance in Requirement 1.

    Click To expand
    Figure 8.14: Network for Exercise 6.

  7. List four types of problems that the performance architecture addresses. Give examples of each type of problem.

  8. For each of the following queuing mechanisms, give an example of how each would be used within a network. What problem(s) is each mechanism solving?

    1. FIFO

    2. CBQ

    3. WFQ

    4. RED

    5. WRED


Chapter 9: Security and Privacy Architecture

Security and privacy of user, application, device, and network resources and data are increasingly important areas of network architecture and design. Security is integrated within all areas of the network and affects all other functions on the network. For the proper functioning of security within a network, it is crucial that the relationships between security mechanisms, as well as between the security architecture and other component architectures, be well understood.

Overlaying security onto a developed network was an acceptable approach in the past. Today, however, security must be integrated into the network from the beginning for the network to meet the needs of the users and for security to provide adequate protection.

9.1 Objectives

In this chapter, you will learn about various security mechanisms (e.g., physical security, protocol and application security, encryption/decryption, perimeter and remote access security), how to determine the relationships both between these mechanisms and between security and the other architectural components, and how to develop the security architecture.


9.2 Preparation

To be able to understand and apply the concepts in this chapter, you should be familiar with the basic concepts and mechanisms of security. Some recommended sources of information include:

  • Hacking Exposed: Network Security Secrets & Solutions, 3rd edition, by Stuart McClure, Joel Scambray, George Kurtz, McGraw-Hill Osborne Media, September 2001

  • Information Security Architecture: An Integrated Approach to Security in the Organization, by Jan Killmeyer Tudor, CRC Press, September 2000

  • Firewalls and Internet Security, William R. Cheswick and Steven M. Bellovin, Addison-Wesley Publishing, January 1994

  • Inside Network Perimeter Security: The Definitive Guide to Firewalls, Virtual Private Networks (VPNs), Routers, and Intrusion Detection Systems, by Stephen Northcutt, Karen Fredrick, Scott Winters, Lenny Zeltser, and Ronald W. Ritchey, New Riders Publishing, June 2002

  • Computer Security Handbook, by Seymour Bosworth and Michel Kabay, John Wiley & Sons, April 2002


9.3 Background

Network security is defined here as the protection of networks and their services from unauthorized access, modification, destruction, or disclosure. It provides assurance that the network performs its critical functions correctly and that there are no harmful side effects. Network privacy is a subset of network security, focusing on protection of networks and their services from unauthorized access or disclosure. This includes all user, application, device, and network data. Whenever the term network security is used in this book, it includes all aspects of network privacy as well.

There are three classic security considerations: protecting (1) the integrity, (2) the confidentiality, and (3) the availability of network and system resources and data. These considerations are discussed throughout this chapter and are integral to the security architecture.

Effective security and privacy is the combination of understanding what security means to each of the components of the system—users, applications, devices, and networks—together with the planning and implementation of security policies and mechanisms.

Security in the network needs to protect network resources from being disabled, stolen, modified, or damaged. This includes protecting devices, servers, users, and system data, as well as the users' and organization's privacy and image.

Attacks against the system range from seemingly innocuous unauthorized probing and use of resources, to keeping authorized users from accessing resources (denial of service), to modifying, stealing, or destroying resources.

This chapter covers how security and privacy may be determined and brought into the network architecture and design. This is an area of great interest and rapid expansion and change in the networking community, so we will present concepts and mechanisms that should be valid across a wide range of security requirements. We will discuss elements of security administration and various security and privacy mechanisms, consider how to develop a security plan, examine requirements for security, define security policies, perform risk analysis for the architecture and design, and develop a security and privacy plan. We will then discuss the security and privacy architecture.


9.4 Developing a Security and Privacy Plan

As discussed in Chapter 5, the development of each component architecture is based on our understanding of why that function is needed for that particular network. Although some may argue that security is always necessary, we still need to ensure that the security mechanisms we incorporate into the architecture are optimal in achieving the security goals for that network. Therefore, toward developing a security architecture, we should answer the following questions:

  1. What are we trying to solve, add, or differentiate by adding security mechanisms to this network?

  2. Are security mechanisms sufficient for this network?

Although some degree of security is necessary for any network, we should have information from the threat analysis to help us decide how much security is needed. As with the performance architecture, we want to avoid implementing (security) mechanisms just because they are interesting or new.

When security mechanisms are indicated, start simple and work toward a more complex security architecture when warranted. Simplicity may be achieved in the security architecture by implementing security mechanisms only in selected areas of the network (e.g., at the access or distribution [server] networks), by using only one or a few mechanisms, or by selecting only those mechanisms that are easy to implement, operate, and maintain.

In developing the security architecture, you should determine what problems your customer is trying to solve. This may be clearly stated in the problem definition or developed as part of the threat analysis, or you may need to probe further to answer this question. Some common areas that are addressed by the security architecture include:

  • Which resources need to be protected

  • What problems (threats) are we protecting against

  • The likelihood of each problem (threat)

This information becomes part of your security and privacy plan for the network. This plan should be reviewed and updated periodically to reflect the current state of security threats to the network. Some organizations review their security plans yearly, and others do so more frequently, depending on their requirements for security.

Note that there may be groups within a network that have different security needs. As a result, the security architecture may have different levels of security. This equates to the security perimeters or zones introduced in Chapter 8. How security zones are established is discussed later in this chapter.

Once you have determined which problems will be solved by each security mechanism, you should then determine whether these security mechanisms are sufficient for that network. Will they completely solve the customer's problems, or are they only a partial solution? If they are a partial solution, are there other mechanisms that are available or that will be available within your project time frame? You may plan to implement basic security mechanisms early in the project and upgrade or add to those mechanisms at various stages in the project.


9.5 Security and Privacy Administration

The preparation and ongoing administration of security and privacy in the network are important to the overall success of the security architecture. As with the requirements and flow analyses, understanding what your threats are and how you are going to protect against them is an important first step in developing security for your network. In this section, we will discuss two important components in preparing for security: threat analysis and policies and procedures.

9.5.1 Threat Analysis

A threat analysis is a process used to determine which components of the system need to be protected and the types of security risks (threats) they should be protected from (Figure 9.1). This information can be used to determine strategic locations in the network architecture and design where security can reasonably and effectively be implemented.

Click To expand
Figure 9.1: Potential assets and threats to be analyzed.

A threat analysis typically consists of identifying the assets to be protected and identifying and evaluating possible threats. Assets may include but are not restricted to the following:

  • User hardware (workstations/PCs)

  • Servers

  • Specialized devices

  • Network devices (hubs, switches, routers, and operations, administration, maintenance, and provisioning [OAM&P])

  • Software (operating system, utilities, and client programs)

  • Services (applications, IP services)

  • Data (local/remote, stored, archived, databases, and data in transit)

And threats may include but are not restricted to the following:

  • Unauthorized access to data, services, software, and/or hardware

  • Unauthorized disclosure of information

  • Denial of service

  • Theft of data, services, software, and/or hardware

  • Corruption of data, services, software, and/or hardware

  • Viruses, worms, Trojan horses

  • Physical damage

A method to gather data about security and privacy for your environment is to put a list of threats and assets together in a worksheet. This threat analysis worksheet can then be distributed to users, administration, and management, even as part of the requirements analysis process, to gather information about potential security problems.

An example of such a worksheet is presented in Figure 9.2. The results shown in this worksheet were determined during the requirements analysis process and are specific to a particular organization. Depending on the organization, the results of a threat analysis can be quite different than those shown in Figure 9.2. For example, a threat analysis can consist of the information and assets that need to be protected, in terms of confidentiality, integrity, and availability. This analysis can be combined with lists of threats that are currently out there, as well as potential vulnerabilities.

Effect/Likelihood | User Hardware | Servers | Network Devices | Software | Services | Data
Unauthorized Access | B/A | B/B | C/B | A/B | B/C | A/B
Unauthorized Disclosure | B/C | B/B | C/C | A/B | B/C | A/B
Denial of Service | B/B | B/B | B/B | B/B | B/B | D/D
Theft | A/D | B/D | B/D | A/B | C/C | A/B
Corruption | A/C | B/C | C/C | A/B | D/D | A/B
Viruses/Worms | B/B | B/B | B/B | B/B | B/C | D/D
Physical Damage | A/D | B/C | C/C | D/D | D/D | D/D
 | Effect: |  |  | Likelihood:
 | A: Destructive | C: Disruptive |  | A: Certain | C: Unlikely |
 | B: Disabling | D: No Impact |  | B: Likely | D: Impossible |

Figure 9.2: Example of threat analysis worksheet for a specific organization.

Threat analyses are by their nature subjective. One way to minimize the degree of subjectivity is to involve representatives from various groups of the organization to participate in the analysis process. This will provide many perspectives in the analysis. It is also recommended that you perform a threat analysis periodically, say, annually, to identify changes in your environment. As an organization grows and changes, and as the outside world changes, the degrees and types of threats to that organization will also change. A periodic threat analysis will ensure that new threats are included and can show where new security mechanisms may be applied to the network. Along with this, a periodic review of security policies and procedures is also recommended. Subsequent reviews may highlight previously overlooked areas in the network, system, and environment.

9.5.2 Policies and Procedures

There are many trade-offs in security and privacy (as with all other architectural components), and it can be a double-edged sword. Sometimes security is confused with control over users and their actions. This confusion occurs when rules, regulations, and security guardians are placed above the goals and work that the organization is trying to accomplish. The road toward implementing security starts with an awareness and understanding of the possible security weaknesses in the network, and then leads to the removal of these weaknesses. Weaknesses are sometimes in the areas of system and application software, the ways that security mechanisms are implemented, and how users do their work. This last area is where educating users can be most beneficial.

Security policies and procedures are formal statements on rules for system, network, and information access and use to minimize exposure to security threats. They define and document how the system can be used with minimal security risk. Importantly, they can also clarify to users what the security threats are, what can be done to reduce such risks, and the consequences of not helping to reduce them.

At a high level, security policies and procedures can present an organization's overall security philosophy. Examples of common high-level security philosophies are to deny specifics and accept everything else or to accept specifics and deny everything else, as in Figure 9.3.

Click To expand
Figure 9.3: Example security philosophies.

In Figure 9.3, the term specific refers to well-defined rules about to whom, what, and where security is applied. For example, it may be a list of specific routes that can be accepted into this network or users who are permitted access to certain resources.

"Deny specifics and accept all else" is an open network philosophy, requiring a thorough understanding of potential security threats, as these should be the specifics to be denied. It can be difficult to verify the security implementation for this philosophy as it is hard to define "all else."

On the other hand, "accept specifics and deny all else" is a closed network philosophy, requiring a thorough understanding of user, application, device, and network requirements, as these will become the specifics to be accepted. It is easier to validate this security implementation as there is a finite (relatively small) set of "accepted" uses. Of the two philosophies, "accept specifics and deny all else" is the common philosophy.

When you develop security policies and procedures, keep in mind that, to be useful, they should be straightforward to implement for your environment (keeping in mind who will be supporting them) and enforceable. They should also have clearly defined areas of responsibility.

Policies and procedures should include:

  • Privacy statements (monitoring, logging, and access)

  • Accountability statements (responsibilities and auditing)

  • Authentication statements (password policies and remote access)

  • Reporting violations (contact information and procedures)

Examples of security policies and procedures are acceptable use statements, security incident-handling procedures, configuration-modification policies, and network access control lists (ACLs). Each of these has a place in the security and privacy plan. These policies and procedures should describe not only how network resources can be accessed, used, and modified but also why to help users understand the policies that they are being asked to accept and work with. Incident-handling procedures can be particularly helpful in making users aware of what to do when a security problem arises, making them part of the security process and not just victims of it. The list of areas for policies and procedures shown here can be used as a starting point to apply to the security architecture:

User access to the system

  • Authorization to use

  • Authentication of identity and use of passwords

  • Training and acceptance of responsibility for compliance

  • Notices that corporate equipment is not private property

  • Expectations of the right to privacy

Administrator skills and requirements for certification

  • Superusers and administrators

System configuration and management

  • Maintenance

  • Virus/ Trojan protection

  • Patching operating systems and applications

  • Monitoring CERT advisories for notices of hacks

  • Who can and cannot connect devices to the network

  • Notice screens during log-in or startup

  • What data get backed up

  • What data get saved off-site

  • Contingency computing plans

What to do when the system is attacked


9.6 Security and Privacy Mechanisms

Several security mechanisms are available today, and many more are on the horizon. However, not all mechanisms are appropriate for every environment. Each security mechanism should be evaluated for the network that it is being applied to based on the degree of protection it provides; its impact on users' ability to do work; the amount of expertise required for installation and configuration; the cost of purchasing, implementing, and operating it; and the amounts of administration and maintenance required.

In this section, we will cover physical security and awareness, protocol and application security, encryption/decryption, network perimeter security, and remote access security.

9.6.1 Physical Security and Awareness

Physical security is the protection of devices from physical access, damage, and theft. Devices are usually network and system hardware, such as network devices (e.g., routers, switches, hubs), servers, and specialized devices, but can also be software CDs, tapes, or peripheral devices. Physical security is the most basic form of security and the one that is most intuitive to users. Nevertheless, it is often overlooked when developing a security plan. Physical security should be addressed as part of the network architecture even when the campus or building has access restrictions or security guards.

Ways to implement physical security include the following (Figure 9.4):

  • Access-controlled rooms (e.g., via card keys) for shared devices (servers) and specialized devices

  • Backup power sources and power conditioning

  • Off-site storage and archival

  • Alarm systems (e.g., fire and illegal entry alarms)

Click To expand
Figure 9.4: Areas of physical security.

Physical security also applies to other types of physical threats, such as natural disasters (e.g., fires, earthquakes, storms). Security from natural disasters includes protection from fire (using alarm systems and fire-abatement equipment), water (with pumping and other water-removal/protection mechanisms), and structural degradation (e.g., through having devices in racks attached to floors, walls). Addressing physical security lays the foundation for your entire network security and privacy plan.

Security awareness is getting users educated and involved with the day-to-day aspects of security in their network and helping them understand the potential risks of violating security policies and procedures. Security awareness can be promoted through providing sessions on security, where users have a chance to discuss issues with security and voice their opinions and problems with security mechanisms, policies, and procedures and potentially offer options for security and privacy; by providing users with bulletins or newsletters (or adding information to the organization's newsletter) on network security and what they can do to help; and by providing users with information on the latest security attacks.

9.6.2 Protocol and Application Security

In this section, we will consider some common protocol and application security mechanisms: IPSec, SNMP, and packet filtering.

IPSec is a protocol for providing authentication and encryption/decryption between devices at the network layer. IPSec mechanisms consist of authentication header (AH) and encapsulating security payload (ESP). There are two modes in which IPSec operates: transport and tunneling. In transport mode, the IP payload is encrypted using ESP and the IP header is left in the clear, as shown in Figure 9.5.

Click To expand
Figure 9.5: Transport mode of IPSec.

In tunnel mode, IPSec can be used to encapsulate packets between two virtual private network (VPN) gateways (IPb and IPc in Figure 9.6).

Click To expand
Figure 9.6: Tunnel mode of IPSec.

The tunneling process consists of the following:

  • IPSec tunnels are created between VPN gateways IPb and IPc in Figure 9.6.

  • IP packets are encrypted using ESP.

  • These packets are then encapsulated within another IP packet, addressed with the ends of the IPSec tunnel (IPb and IPc).

  • At the end of the tunnel (the VPN gateway serving IPd), the original packet is unencapsulated and decrypted and sent to its destination (IPd).

This is an example of tunneling, or encapsulating information within protocol headers for the purpose of isolating and protecting that information. Note that this is different from traditional protocol encapsulation, which is used to support varying functions at each protocol layer. VPNs apply this tunneling concept to create multiple isolated networks across a common infrastructure.

Tunneling and VPNs are common methods for building an isolated network across a common infrastructure such as the Internet.

Security for the SNMP version 3 (SNMPv3) is described in the user-based security model (USM), protecting against modification of information, masquerades, disclosure (eavesdropping), and message stream modification. SNMP security provides the following security capabilities:

  • SNMP message verification (data integrity), user identity verification (data origin authentication), and data confidentiality (via authProtocol, authKey, privProtocol, privKey)

  • Detects SNMP messages that have exceeded time thresholds (message timeliness/limited replay) (via snmpEngineID, snmpEngineBoots, snmpEngineTime)

SNMP security also includes authentication mechanisms (authProtocol) and encryption/decryption mechanisms (privProtocol):

  • HMAC-MD5-96 (128-bit message digest algorithm [MD5] cryptographic hash function, message-authentication codes [HMAC] mode, truncated to 96 bits)

  • HMAC-SHA-96 (secure hash algorithm)

  • CBC-data-encryption standard (DES) Cipher Block Chaining Mode Symmetric Encryption/Decryption Protocol

SNMP security also provides for modifying management information base (MIB) views and access modes. For example, it is possible to have different MIB views definable for different groups, and access modes (RO, RW) are also definable for different groups and are tied to MIB views.

Packet filtering is a mechanism in network devices to explicitly deny or pass packets at strategic points within the network. They are often used to deny packets to or from particular IP addresses or ports (services), as in Figure 9.7.

Click To expand
Figure 9.7: Example of packet filtering.

9.6.3 Encryption/Decryption

Although other security mechanisms provide protection against unauthorized access and destruction of resources and information, encryption/decryption protects the information from being usable by the attacker. Encryption/decryption is a security mechanism in which cipher algorithms are applied together with a secret key to encrypt data so that they are unreadable if they are intercepted. Data are then decrypted at or near the destination. This is shown in Figure 9.8.

Click To expand
Figure 9.8: Encryption/decryption of network traffic.

As such, encryption/decryption enhances other forms of security by protecting information in case other mechanisms fail to keep unauthorized users from that information. There are two common types of encryption/decryption: public key and private key. Software implementations of public key encryption/decryption are commonly available. Examples include DES private key encryption, triple DES private key encryption, and Rivest-Shamir-Adleman (RSA) public key encryption.

Public key infrastructure (PKI) is an example of a security infrastructure that uses both public and private keys. Public key infrastructure is a security infrastructure that combines security mechanisms, policies, and directives into a system that is targeted for use across unsecured public networks (e.g., the Internet), where information is encrypted through the use of a public and a private cryptographic key pair that is obtained and shared through a trusted authority. PKI is targeted toward legal, commercial, official, and confidential transactions and includes cryptographic keys and a certificate management system. Following are components of this system:

  • Managing generation/distribution of public/private keys

  • Publishing public keys with user IDs (UIDs) as certificates in open directories

  • Ensuring that specific public keys are truly linked to specific private keys

  • Authenticating the holder of a public/private key pair

PKI uses one or more trusted systems known as certification authorities (CAs), which serve as trusted third parties for PKI. The PKI infrastructure is hierarchical, with issuing authorities, registration authorities, authentication authorities, and local registration authorities.

Another example is the secure sockets library (SSL). SSL is a security mechanism that uses RSA-based authentication to recognize a party's digital identity and RC4 to encrypt and decrypt the accompanying transaction or communication. SSL has grown to become one of the leading security protocols on the Internet.

One trade-off with encryption/decryption is a reduction in network performance. Depending on the type of encryption/decryption and where it is implemented in the network, network performance (in terms of capacity and delay) can be degraded from 15% to 85% or more. Encryption/decryption usually also requires administration and maintenance, and some encryption/decryption equipment can be expensive. Although this mechanism is very compatible with other security mechanisms, trade-offs such as these should be considered when evaluating encryption/ decryption.

9.6.4 Network Perimeter Security

For network perimeter security, or protecting the external interfaces between your network and external networks, we will consider the use of address translation mechanisms and firewalls.

Network address translation (NAT) is the mapping of IP addresses from one realm to another. Typically this is between public and private IP address space. Private IP address space is the set of Internet Engineering Task Force-defined private address spaces (RFC 1918):

Class A | 10.x.x.x | 10/8 prefix
Class B | 172.16.x.x | 172.16/12 prefix
Class C | 192.168.x.x | 192.168/16 prefix

NAT is used to create bindings between addresses, such as one-to-one address binding (static NAT), one-to-many address binding (dynamic NAT), and address and port bindings (network address port translation [NAPT]).

Although NAT was developed to address the issues of address space exhaustion, it was quickly adopted as a mechanism to enhance security at external interfaces. Routes to private IP address spaces are not propagated within the Internet, so the use of private IP addresses hides the internal addressing structure of a network from the outside.

The security architecture should consider a combination of static and dynamic NAT and NAPT, based on the devices that are being protected. For example, static NAT is often used for bindings to multiple-user devices such as servers or high-end computing devices, and dynamic NAT is used with generic computing devices.

Firewalls are combinations of one or more security mechanisms, implemented in network devices (routers), that are placed at strategic locations within a network. Firewalls can be filtering gateways, an application proxy with filtering gateways, or a device running specialized "firewall" software.

9.6.5 Remote Access Security

Remote access consists of traditional dial-in, point-to-point sessions, and VPN connections, as shown in Figure 9.9.

Click To expand
Figure 9.9: Remote access mechanisms.

Security for remote access includes what is commonly known as AAAA: authentication of users, authorization of resources to authenticated users, accounting of resources and service delivery, and allocation of configuration information (e.g., addresses or default route). AAAA is usually supported by a network device such as a network access server (NAS) or subscriber management system (SMS).

Remote access security is common in service-provider networks (see also the service-provider architectural model in Chapter 5), but it is evolving into enterprise networks as enterprises recognize the need to support a remote access model for their networks.

Considerations when providing remote access include the following (Figure 9.10):

  • Method(s) of AAAA

  • Server types and placement (e.g., demilitarized zone [DMZ])

  • Interactions with DNS, address pools, other services

Click To expand
Figure 9.10: Remote access considerations.

Figure 9.11 shows the protocol interaction of the Point-to-Point Protocol (PPP), PPP over Ethernet (PPPoE) and remote access dial-in user service (RADIUS) in a remote access network.

Click To expand
Figure 9.11: Process for PPP/PPPoE session establishment.

Figure 9.11 shows the process of establishing a PPPoE session, upon which a PPP session is started. PPPoE provides a shim between Ethernet and PPP, supporting the point-to-point nature of PPP sessions over a broadcast Ethernet network.

Thus, a PPPoE session starts with a broadcast packet, the PPPoE active discovery initiation (PADI). This packet begins a handshake between the user's computer and the NAS, consisting of PADI, PPPoE active discovery offer (PADO), PPPoE active discovery request (PADR), and PPPoE active discovery session (PADS) packets. The PPP session can begin at the completion of this part of the process.

A PPP session has three stages: link establishment, authentication, and network layer. Each stage builds on the previous one to establish the PPP session. Once PPPoE and PPP sessions have been established, the user can begin using the network.

Authentication in a remote access network is typically accomplished via a combination of PPP, PPPoE, PAP, CHAP, and RADIUS protocols.

Other authentication mechanisms at the remote access network include tokens, smart cards, digital certificates, and callback. VPNs and tunnels can also be considered part of the remote access network.

VPNs are an example of what can be considered a subarchitecture. VPNs, by themselves, can require their own set of architectural considerations. This is particularly true when they make an extranet, which is an intranet extended to include access to or from selected external organizations (e.g., customers, suppliers), but not to the general public. Such considerations include equipment types, tunneling protocols and security, VPN locations, policies on VPN provisioning and support, and the use of routing protocols such as the Border Gateway Protocol (BGP) or multiprotocol label switching (MPLS).

Finally, remote access security should also consider wireless communications and portable computing devices using standards such as 802.11 and homephoneline networking alliance (homePNA). Wireless can target a number of environments, such as mobility, portability, and nomadic computing.


9.7 Architectural Considerations

In developing our security architecture, we need to evaluate potential security mechanisms, where they may apply within the network, as well as the sets of internal and external relationships for this component architecture

9.7.1 Evaluation of Security Mechanisms

At this point, we should have requirements, goals, type of environment, and architectural model(s), so we are ready to evaluate potential security mechanisms. As with each component architecture, when evaluating mechanisms for an architecture, we should start simple and work toward more complex solutions only when necessary.

Where a security mechanism will apply in a given network will depend primarily on where security requirements are located throughout the network and what the security requirements are based on the results of the requirements analysis and the security and privacy plan.

The architectural models presented in Chapter 5 can help determine where security mechanisms can be applied in the network. For example, the access/distribution/ core architectural model, which separates a network based on function, can be used as a starting point for applying security mechanisms. Using this model, we can increase security at each level, from access network to distribution networks to core networks, by either adding security mechanisms or enhancing the amount of security provided by each mechanism. This is shown in Figure 9.12.

Click To expand
Figure 9.12: Access/distribution/core architectural model as a starting point for security.

In Figure 9.12, security is increased from access to distribution to core areas, either by adding security mechanisms at each area or by increasing the level of security (i.e., enhancing security) at each level. For this architectural model, most traffic flows are sourced/sinked at access networks and travel across distribution and core networks. Through the addition of mechanisms or enhancement of mechanisms at each level, a traffic flow will encounter higher levels of security as it moves from access to distribution to core networks.

In Figure 9.12, traffic flows from User A to User C travel across both access and distribution networks and would encounter two levels of security, level 1 and level 2 firewalls, where level 2 would be a greater level of security than level 1. A level 2 firewall may have a more complete ACL, stricter rules for filtering traffic, or greater logging and detection capability.

Traffic flows from User C to User A travel across access, distribution, and core networks. As traffic moves from User C to the core network, it would encounter multiple security mechanisms (intrusion detection, firewalls, encryption/decryption, and packet filters), with security increasing from access to distribution to core. In addition, as traffic moves from the core network to User A, it will encounter three levels of firewalls. In a similar fashion, the service-provider and intranet/extranet architectural models can also be used to develop a framework for security in a network.

As mentioned in Chapter 8, security perimeters (i.e., security zones or cells) can be developed within a network to accommodate multiple different levels of security requirements. Two common methods of developing security zones are to increase security as you move deeper into the network (an example of this is shown in Figure 9.12) or to develop zones wherever they are needed in the network, regardless of topology.

When security zones are developed to increase security as you move deeper into a network, they become imbedded within each other, as shown in Figure 9.13. In a sense the security levels look like the layers of an onion, with the innermost layers having the highest level of security.

Click To expand
Figure 9.13: Security zones embedded within each other.

Security zones are based on the various security requirements determined during the requirements analysis process and should be described in the security and privacy plan. There may be requirements for different levels of security, coupled to groups of users, their applications, their devices, or devices that are shared among users. Security zones developed to meet such requirements may be scattered throughout the network and may even overlap one another. An example of this is presented in Figure 9.14.

Click To expand
Figure 9.14: Developing security zones throughout a network.

In Figure 9.14, five security zones are shown, based on different security requirements. The first zone (security level 1) covers the entire network and is intended to provide a general level of security for all users, applications, and devices. This may include intrusion detection and logging. The second zone (security level 2) provides a higher level of security between this network and all external networks. This may include NAT and firewalls.

The third zone (security level 3) provides another level of security for an entire group of users, applications, and/or devices (Group D), whose security requirements are different from the rest of the network. For example, this group may handle financial and/or proprietary information for the company. The fourth zone (security level 4) provides security for a subset of users, applications, and/or devices from multiple groups (Groups A and B). These are select users, applications, and/or devices whose security needs are different from others in their groups. For example, they may be working on company-classified projects, producing data that need to be protected from the rest of the groups. The third and fourth zones may apply mechanisms to protect their data, such as encryption/decryption, and may have access protection via firewalls and/or packet filtering. The fifth zone (security level 5) is security for devices that are used by multiple users, such as servers. This zone may employ monitoring, logging, and authentication to verify user access.

Figures 9.12, 9.13, and 9.14 show how security mechanisms may be applied in a network to achieve multiple different security levels or zones.

9.7.2 Internal Relationships

Interactions within the security architecture include trade-offs, dependencies, and constraints between each of the security mechanisms for your network. Some examples are presented here.

Interactions between Encryption/Decryption and Other Security Mechanisms

Some security mechanisms require the ability to look at, add to, or modify various information fields within the packet. For example, NAT changes IP address information between public and private address domains. Encryption/decryption mechanisms may encrypt information fields, making them unreadable to other mechanisms.

9.7.3 External Relationships

External relationships are trade-offs, dependencies, and constraints between the security architecture and each of the other component architectures (addressing/routing, network management, performance, and any other component architectures you may develop).

There are common external relationships between security and each of the other component architectures, some of which are presented in the following sections.

Interactions between Security and Addressing/Routing

NAT is an addressing mechanism that is often used to enhance security. Therefore, when it is applied for security, it will also impact addressing for the network. In addition, dynamic addressing can interfere with address-specific protective measures and logging. It is more difficult to determine what is going on when IP addresses are changed frequently.

Interactions between Security and Network Management

Security depends on network management to configure, monitor, manage, and verify security levels throughout the network. In addition, there is a need for maintenance access even during attacks where in-band access to network devices is not available. For example, when devices are not at the same location, using dial-up for out-of-band access is a potential fallback position to take.

Interactions between Security and Performance

Security and performance are often at odds, as security mechanisms can affect network performance. The security zones described earlier in this chapter can constrain performance within the areas described by the zones. When security is a high priority, security mechanisms that impact traffic flows may restrict performance mechanisms to operate within security zones or result in performance being minimized for that zone (Figure 9.15).

Click To expand
Figure 9.15: Security mechanisms may restrict or preclude performance within each zone.

When performance is high priority, particularly when there is a need to provision end-to-end performance between select users, applications, or devices, performance mechanisms may preclude the use of intrusive security mechanisms in those areas of the network.


9.8 Conclusion

In this chapter, we discussed various potential security mechanisms for your security architecture, including physical security, protocol and application security, encryption/ decryption, and perimeter and remote access security. Based on information from the requirements analysis, we developed input for a security and privacy plan. We also discussed elements of both internal and external relationships for the security architecture.


9.9 Exercises

For Exercises 1 through 3, refer to Figure 9.16.

Click To expand
Figure 9.16: Network for Exercises 1 through 3.

  1. Develop a sample threat analysis for the network in Figure 9.16 or for a network with which you are familiar. Show assets and potential threats as in Figure 9.2.

  2. Apply the security mechanisms from this chapter to support the following requirements. Show where each mechanism might be applied.

    1. An intranet between each of the routers connected to the WAN.

    2. Remote access security must be provided for each of the 15 dial-up routers connected to the LAN in Washington, DC.

    3. All traffic flows between Los Angeles and Minneapolis must be encrypted.

  3. Outline the development of DMZs that would be applied at each site where connections are made to other autonomous systems (AS). What types of devices would be used at these sites?

  4. Figure 9.17 shows five security zones required by the customer. These zones are prioritized, such that security zone 5 provides basic security for the entire network, and zones 2, 3, 4, and 5 have increasing degrees of security, and security zone 5 has the highest level of security. For this network:

    1. What security mechanisms can be applied within each security zone and at the interfaces between security zones, to achieve increasing degrees of security?

    2. Which architectural models are most applicable to this network? Show how each model can be applied.

    Click To expand
    Figure 9.17: Network for Exercise 4.


Chapter 10: Selecting Technologies for the Network Design

Selecting technologies is the first part of the network design process. We will use all of the material we have developed through the analysis and architecture processes to make these technology choices. Technology selection, along with interconnecting technologies, provides the details needed for a network design.

10.1 Objectives

In this chapter, you will learn the process of selecting network technologies for your design. You will learn to apply the various sources of information that you have gathered, derived, and developed, including requirements, flows, goals, criteria, and guidelines, to making technology selections. Developing a set of design goals and evaluation criteria are critical to making technology choices, and most of this chapter focuses on these areas. You will also learn about tools to help with the technology selection process, in particular how to segment a design into areas and how to apply the black-box method to focus on each area of the design.


10.2 Preparation

To be able to understand and apply the concepts in this chapter, you should be familiar with the various technologies used in networks, including the varieties of Ethernet, ATM, frame relay, and packet over synchronous network (SONET) (PoS). The following is a recommended source of more information:

  • Interconnections: Bridges, Routers, Switches, and Internetworking Protocols, 2nd edition, Radia Perlman, Addison-Wesley Publishing, October 1999

  • Essentials of ATM Networks and Services, by Oliver Chukwudi Ibe, Addison-Wesley Publishing, January 1997

  • ATM and SONET Basics, by George Dobrowski and Donald Grise, APDG Publishing, January 2001

  • Switched, Fast, and Gigabit Ethernet, by Sean Riley and Robert A. Breyer, New Riders Publishing, January 1999

  • Frame Relay: Technology and Practice, by Jeff T. Buckwalter, Addison-Wesley Publishing, December 1999


10.3 Background

To make the design process more straightforward, I have separated the design of the network into making technology choices and determining interconnection mechanisms. At this point in the process, we should have the requirements specification, with its user, application, device, network, and other requirements; the requirements map, which shows the locations of applications and devices; the flow specification, with its performance characteristics for individual and composite flows, flow models, and data sources and sinks; and the component architectures for performance, security and privacy, network management, and addressing and routing. We will use all of this information as input to the network design.

Network design consists of determining your design goals for the network and translating these goals into evaluation criteria for making technology choices for the design. The network is then segmented into small, workable areas, and technology choices are made for each area based on the evaluation criteria. After making our technology choices, we will determine how to interconnect areas of the design. We will also look at various interconnection mechanisms and where they may apply in the design.

The technologies that will be discussed in this chapter may be at different stages of development, testing, or deployment based on when this material is applied to the design. When evaluating and selecting technologies for your design, check the current (or expected) state of each candidate technology before applying it to the design to ensure that your technology choices can be implemented.

Figure 10.1 shows the process model for making technology choices for a network design. Input to the design comes from the results of the requirements specification and map, the flow specification and map, and the reference architecture. This information is used to establish design goals for the network and to develop criteria to evaluate candidate technologies. Guidelines for technology evaluation, presented in this chapter, are used in conjunction with the evaluation criteria to make technology selections.

Click To expand
Figure 10.1: Process for selecting technologies for the network design.

One of the results of the design process will be one or more diagrams describing where each of the technologies applies within the network. These diagrams will be combined with diagrams describing the network architecture and interconnection mechanisms for a complete description of the network. This complete set of diagrams will then be used to prepare and plan for the network, including, for example, writing a request for proposal (RFP), ordering equipment, deploying cable, and writing the transition plan for the network.


10.4 Developing Goals for the Network Design

In choosing candidate network technologies for the design, applying them to the design, and determining how to connect them, we need to have a set of clearly defined goals for the network design. Developing design goals is part of understanding what is expected from the network, and thus, from the design.

Design goals dictate the characteristics to be used to optimize a network design. All design goals for a network project should be listed at this point in the process so that the design is properly balanced to meet all of the goals.

Design goals should be closely coupled to the architectural goals discussed earlier in this book. In fact, design goals may be derived directly from architectural goals. You may be able to identify a single primary design goal for your network, one that will drive the design. For example, a common design goal is to minimize the costs for the network. Another goal may be to maximize performance of the network, in general or for a specific application, device, or group of users. Yet another design goal may be to maximize security for the network, across the entire network for particular locations (e.g., at interfaces to external networks). In doing the network analysis (requirements, flow, and possibly risk analyses) for your network, you might find that such design goals may already be clear.

Common design goals include optimizing the following:

  • Network deployment and operations costs, including the costs for circuits and services

  • Security, including maximizing security across the network, mapping security to a particular group's requirements, or providing multiple security models within the network

  • One or more network performance characteristics

  • Ease of use and manageability of the network

  • Adaptability to new and changing user, application, and device needs

  • Supportability of the network

As with the network architecture, keep in mind that there are trade-offs between design goals. For example, a primary design goal of minimizing costs may lead to choices that trade off performance, security, ease of use, or adaptability for cost. Alternatively, if optimizing security is a primary design goal, it may lead to choices that trade-off cost and performance for security. Such trade-offs are not a problem as long as you understand what they are, know how they relate to the network design goals, and have them well documented.

The initial conditions (scope, scale, and problem definition) for your network project can indicate what your design goals will be. If you are designing a brand-new network for an environment that currently does not have any networking, then you will be free from the requirements and constraints of existing networks. Your design may call for the building of a scalable infrastructure, a high-performance backbone, or specialized workgroups. If you are designing a network upgrade, adding to an existing network, or adapting a network to a new application, then you are faced with the existing networks, along with their infrastructures, technologies, and protocols, as well as users who are familiar with working on those networks. For these types of environments, you may be guided by making the network transition as easy as possible, minimizing disruption to the existing networks, and may trade off other goals to meet these.

The requirements and flow analyses can also indicate design goals for the network. For example, requirements for guaranteed or predictable performance are an indication of high-performance, relatively sophisticated solutions. Composite flows indicate traffic consolidation, where capacity sharing and cost management can be applied. In the flow analysis, the unitary, two-part, and multipart flowspecs provide flow information for service and capacity planning, which directly correlate to the goals listed earlier. Service planning implies maximizing one or more performance characteristics, as well as providing security and adaptability to users and management. Capacity planning, on the other hand, can be used to optimize the available capacity of the network, which, in turn, can be used to optimize network costs and ease of use.

Another consideration is that design goals may change in priority from one part of a network to another. You may have a user group that requires high performance in a particular area (e.g., a server farm or computing cluster), which will require a high-cost solution, and the rest of the network is optimized to reduce costs.

It is possible that, in trying to establish your goals, you will find that users want everything: a solution that is low cost, high performance, easy to use and maintain, and adaptable to the users' changing needs. At this point you can do the following:

  1. Pull you hair out (if you have any left by now)

  2. Arbitrarily choose one or more goals

  3. Attempt to show the trade-offs between goals to the users (and management)

  4. Let the users and management prioritize their goals for the system

You can develop an argument for or against a design goal by developing a list of trade-offs associated with the design goal and presenting them to users and management. One often-used argument is the trade-off between cost and performance. A graph showing the relative costs of technologies, listed for each area of the network, allows those who make funding decisions to pick the level(s) of performance and to understand the costs associated with each level.

Figure 10.2 is an example of a graph comparing costs and performance for candidate technologies. A graph like this can be used to show that, for extra funding, a different technology or set of technologies can be used that will bring better performance or function to users, applications, and devices.

Click To expand
Figure 10.2: Cost/performance graph.

The result of determining your design goals is a set of prioritized goals, based on a primary design goal and one or more secondary goals. The primary design goal will override other goals when considering trade-offs between goals and will tend to drive the design. When the primary goal is met, secondary goals are used to complete the design. There are times when a design goal will also be a constraint on the design. Constraints are boundaries that we will not be allowed to cross or that we will have to pay a penalty to cross. Examples of constraints are overall deployment or operations budgets, strict network performance requirements, physical factors such as network distances and latencies, or deployment time schedules.

For example, let's consider a design project in which we are going to build a local workgroup network. For this design, we have been budgeted $1 million to be used to purchase PCs and the network. Each PC (or laptop) costs about $1000, and we are required to have between 300 and 600 new PCs in the network, depending on how much we spend on the network. However, we cannot have fewer than 300 PCs in the network. These PCs will be working together in workgroups of 30 to 60, and their performance requirements are estimated as 80 Mb/s capacity and a less than 100-ms delay between any two PCs in a workgroup.

For this design project, we are constrained by costs, the minimum number of PCs in the network, and by performance, particularly delay within a workgroup. A graph of budget allocations for PCs and the network—including network interface cards (NICs), LAN/workgroup hardware and software, and cable infrastructure if necessary—would look like Figure 10.3.

Click To expand
Figure 10.3: Budget allocation for example.

Figure 10.3 shows the range of network and PC costs, which will total $2 million and provide between 300 and 600 PCs for the network. This graph also shows the available technologies within allowable network costs. If we have a primary design goal of minimizing the overall budget for this project, we could choose to minimize the number of PCs, which will give us more funds for the network (possibly providing better network performance) while reducing the overall budget. If the design goal is to maximize network performance, we could reduce the number of PCs (somewhere between 300 and 600) and use all of the remaining funds for the network, which will not reduce the overall budget but will maximize the funds available for the network. Another possible design goal for this environment could be to make this workgroup network available to as many users as possible. This would drive us to maximize the number of PCs in the network, reducing both funding for the network and probably network performance.

Thus, the choices we make for primary and secondary design goals will affect our evaluation of the network design. It is important that you understand your design goals as you begin the design process.


10.5 Developing Criteria for Technology Evaluation

In preparation for making technology choices for a network design, we will examine technology characteristics that are important from a design perspective. Input to developing evaluation criteria comes from the design goals for the project, the results of the requirements analysis, along with the service-planning and capacity-planning information from the flowspec.

Design goals can often be used directly as evaluation criteria or can easily be translated into evaluation criteria. Minimizing network deployment and operations costs and maximizing ease of use for users and management lead to choosing technologies that are relatively simple and intuitive to deploy, use, and maintain. This also leads to choosing technologies that are standards based, commonly available, and well documented. Commercial off-the-shelf (COTS) network products often fall into this category.

Maximizing performance leads to choosing technologies that meet or exceed expected capacity, delay, and/or reliability, maintainability, and availability (RMA) requirements (from the requirements analysis). Maximizing RMA will also indicate a need for interconnectivity (redundancy) in the network. Redundancy may be achieved in a number of ways, through the choice of technologies, how each technology is applied in the network, redundancy in routing protocols, or redundancy in the physical infrastructure. Usually redundancy is achieved through applying several of these techniques together in the network. Technologies that maximize performance are likely to be more complex solutions, trading off the criteria of simplicity and costs. Performance may also indicate a need for predictable and/or guaranteed service in the design, which will require technologies and protocols that can support predictable and/or guaranteed service delivery.

Adaptability is acknowledging that the design project will be dynamic and that your technology choices will need to support dynamic behavior, such as rapid reconfiguration of users, user groups, address assignments, routing, and location changes on the network. An example of adaptability in a WAN would be to choose a network service (e.g., virtual private networks) from a service provider instead of building a private WAN infrastructure. Another example is providing virtual LAN capability in a LAN to support the dynamic allocation of resources to users. Many examples of adaptability are related to the concept of virtual networks. Adaptability may also be applied to traffic flows to distinguish between flows and switch or route each flow independently based on the requirements of each flow.

Supportability is a measure of how well the customer can keep the system performing, as designed, over the entire life of the system. Can the support staff operate and maintain the proposed technologies? Does the support staff need to be trained on the new technologies, or should they be replaced or augmented with a more technically qualified staff? Should the customer consider outsourcing part or all of the operations and maintenance to a service organization?

In addition, the reference architecture provides input to the design goals. This input consists of how each proposed technology achieves the reference architecture, made up of the component architectures (e.g., addressing/routing, network management, performance, security).

From the flowspec, we can do service and capacity planning. With service planning, we expect some degree of predictable and/or guaranteed performance from the network. This indicates that one of the important design goals will be to maximize one or more network performance characteristics. Some of the other design goals related to service—ease of use and manageability, optimizing security, or adaptability— may also be important in service planning.

In contrast, capacity planning implies that capacity requirements from multiple sources—users, applications, and devices—will be combined across a common technology. This is one of the considerations when trying to optimize costs for the network. Thus, the design goal of minimizing network deployment or operations costs can be part of capacity planning. This does not mean that service planning excludes cost optimization or that capacity planning excludes services. Rather, service and capacity planning help determine what the design goals should be. Figure 10.4 illustrates this relationship between capacity and service plans (from the flow analysis) with network architecture and design goals.

Click To expand
Figure 10.4: Requirements, flows, and network architecture influence design goals.

Once we have decided what the design goals are for the network, we look at the characteristics of technologies that will help us achieve our design goals. There are likely to be characteristics that are important to a particular network, as well as general characteristics that are applicable across most networks. Some general characteristics we will consider here are broadcast and nonbroadcast multiple-access (NBMA) methods, technology functions and features, performance upgrade paths, and flow considerations.

10.5.1 Broadcast and Nonbroadcast Multiple-Access Methods

In developing criteria to evaluate and choose network technologies for your design, we want to look beyond their traditional characteristics—capacities, for example, to find other characteristics that are important from a design perspective. In addition to the capacities of technologies, we can find differences in the design characteristics of broadcast and NBMA technologies, in the types of services that they can support, their upgrade paths, and how they can meet the capacity and service plans of the flow specification.

In developing evaluation criteria, we can consider two important distinguishing characteristics between broadcast and NBMA technologies: native broadcast support and connection support.

Native Broadcast Support

Broadcast technologies support the ability of a device to communicate simultaneously with all other devices on the network or subnet, through using a well-known broadcast address specific to the network technology. This means that every device on the network or subnet can find and access every other device on that network.

To begin with, let's consider this in the context of IP networking. One fundamental requirement of every IP subnet is that every device must be able to directly communicate with every other device on that subnet. This requires the underlying (layer 2) network technology to provide a mechanism to resolve any layer 3 (IP) address for that subnet into the corresponding layer 2 address.

To accomplish this, the technology must have the ability to reach all devices on the subnet, or broadcast on the subnet. The mechanism that resolves layer 3 addresses into corresponding layer 2 addresses is commonly known as the Address Resolution Protocol (ARP). Whereas this is taken for granted in older, broadcast technologies such as Fast Ethernet, Gigabit Ethernet, 10-Gigabit Ethernet, Token Ring, and fiber distributed data interface (FDDI), it can be an issue for NBMA technologies.

NBMA technologies do not inherently have a broadcast mechanism. This is not necessarily a problem, but it does mean that we will need to consider how IP address resolution will be supported in the NBMA environment. Depending on the technology and how it is used in the network, there are a number of mechanisms for supporting address resolution, including hardwiring layer 3 to layer 2 address bindings in devices, using vendor-specific broadcast support mechanisms, or using one of the evolving standards-based mechanisms. NBMA technologies include ATM, frame relay, switched multimegabit data service (SMDS), and high-performance parallel interface (HiPPI). When a network design incorporates an NBMA technology, the design will need to ensure that broadcast (and multicast) is provided for those services that need them.

Another way to look at the lack of an inherent broadcast mechanism is that we have some flexibility in how we provide broadcast in the network. Since broadcast can be considered a mechanism for local directly connected access, it has been one of the factors coupling logical networks with physical networks. Some NBMA networks can be flexible in their handling of broadcasts, so we can create logical subnets that are not coupled to any physical topology. This is an often-overlooked powerful design option that we will see many times throughout this book. Of course, a trade-off with decoupling logical and physical networks is an ambiguity about the underlying network. When a physical network can contain a variety of logical networks (which may themselves be dynamic), it will require more information and more sophisticated techniques of monitoring and management, as we will see later.

When choosing appropriate technologies for the network, you must understand the nature of broadcast for each technology and what role(s) broadcast will play in your design. There are trade-offs between NBMA and broadcast technologies that will be of interest to us, including scalability and simplicity.

One of the fundamental principles of network design is that hierarchies form in the network as groups become larger. Groups can be of users, devices, applications, or higher-level abstractions of these, such as areas or autonomous systems (ASs). An AS is one way to define an administrative domain (a set of networks that are administered by the same organization), where an AS number identifies the administrating organization. A group may also be thought of as a collection of devices that have direct access to each other (e.g., an IP subnet or broadcast domain). As groups get larger, the broadcast traffic (or other secondary effects) becomes more and more of a burden on the network, until it degrades or disrupts performance. Thus, we want to keep group sizes manageable. As a result, hierarchies form to separate groups.

Group sizes are intertwined with our technology choices and information from the flow specification. We want to size groups so that the steady-state background broadcast traffic is a small percentage (a good guideline is less than 2%) of the capacity of the technology. For a 100 Mb/s Ethernet network, we would expect the background broadcast traffic to be no more than about 2 Mb/s. To turn background broadcast numbers into group sizes, we need to estimate how much broadcast traffic a source is likely to generate.

For a broadcast network, this group size would equate to the number of connections to the physical network (e.g., a shared Ethernet, Token Ring, or FDDI network) or to the number of ports on a switch (as in switched Ethernet, Token Ring, FDDI, or ATM) or hub. We need to keep in mind that there are other sources of background broadcast traffic, such as from routing protocols and that this needs to be taken into account also.

Connection Support

Another consideration for broadcast and NBMA technologies is their connection support. Connection support is when a connection is established by the technology whenever information is transferred across the network. A connection is an abstraction of mapping addresses (typically layer 2 addresses) across a network. These addresses may have end-to-end significance, if, for example, we use IP source and destination addresses, or they may have local significance, such as virtual circuit address mapping at ATM switch ports. To do this mapping connection, support is tied to the ability of the technology to get state information, or state, about the network. State is information (typically local/end-to-end addresses, routing information, or quality of service) associated with connections and paths in a technology.

In a sense, a connection-oriented technology must be able to get and persistently maintain address configuration and status information about its end-to-end connections. This is one form of providing state. We will examine three forms of state: hard state, soft state, and stateless (or no state).

Hard state is determining and persistently maintaining connection information along the path of a connection, between source and destination. Stateless is not having to determine or maintain any connection or path information between source and destination. Soft state is between hard state and stateless, determining and maintaining state either until the connection is established or for a short period after the connection is established. Thus, although there is state information being kept, this information is not persistent. It may be kept in short-term memory, or cached, on the order of seconds or minutes.

Stateful, either hard or soft state, is often used to describe a connection-oriented technology, and stateless to describe a connectionless technology. Here, we will default to these descriptions, but bear in mind that this does not always have to be the case. For example, state can be determined and maintained by the network or transport protocols, making a "connection" at that layer in the network. A connectionless technology does not itself have connection information and does not need to maintain state information (hard or soft state) within the network to transfer data.

Sometimes a technology or combination of technologies and protocols may allow operation somewhere between connection-oriented and connectionless, treating some traffic as if it were transiting a connectionless path and other traffic a connection-oriented path. Deciding how to handle different traffic flows may be based on source or destination address, on flow information (e.g., estimated amount of flow or flow type), or on some other session-based information.

A trade-off between using a stateful or stateless technology is the amount of overhead required to establish and maintain state versus the control over the end-to-end path enabled by having state. A connection-oriented technology can offer support for services to a session (an instance of one or more concurrent applications, resulting in one or more traffic flows), based on factors such as cost or performance, and may be able to support monitoring and verification of the service for each session. If we are interested in supporting predictable and/or guaranteed flows in the network, a connection-oriented approach is often required.

There are various types of overhead in supporting connections; in network resources (CPU, memory, capacity); and in monitoring, management, and security requirements. There is also a cost in the setup and tear-down times for connections. When traffic flows for a session are short lived, on the order of one or a few packets, frames, or cells, then setup overhead, in terms of time and allocation of resources, can substantially reduce the performance of the connection (and ultimately, that of the applications generating sessions over that connection).

To balance these trade-offs and optimize the use of multiple technologies, some hybrid connection approaches are evolving. They use some state information to make decisions and apply timeouts to eliminate "old" state information. This is what is considered soft state. In Figure 10.5, state is shown being gathered from each device in the end-to-end path of a traffic flow.

Click To expand
Figure 10.5: System state.

Connection support is important when evaluating technologies on the basis of scalability and flexibility, as well as in how services are offered on the network. Basically, the more control we wish to have over end-to-end services that a network will offer, the greater the tendency toward applying connection-oriented technologies. Of course, there are trade-offs in getting more control over an end-to-end connection, and here we need to consider the overhead with connections, the setup and tear-down times, and the need for greater configuration control and management. For many networks, the gain in end-to-end control is worth the costs of these trade-offs.

Consider a technology in which connections are made for each application session (and thus for each traffic flow). There will be a delay while the connection is being built (setup), and this delay can be significant (up to seconds in duration) depending on how much recent state information is available locally or, if it is not available, how long it takes to get this information (which is based on the signaling capability of the technology). Some applications may not be able to wait for this connection setup time and meet the performance expectations of their users. Network file server (NFS), for example, is a local disk-access utility. Therefore, its total network disk-access delay must approximate local network disk input and output.

In addition, each network device for a technology in the path of a connection will keep some state information, local or global, about that connection. This requires memory and CPU usage that could otherwise be made available to other processes. In Figure 10.6, connection state information such as device, resource, and network addresses is requested by the application or device that is establishing the connection, as part of determining whether the connection can be set up, the required resources can be allocated, and the connection maintained.

Click To expand
Figure 10.6: System state as part of network connections.

The benefits of greater control over end-to-end connections can be substantial in some networks. When predictable or guaranteed services are required, a connection-oriented technology with its state information may be the only viable solution. If a network is being designed for mission-critical, real-time, and/or interactive-burst applications (such as the visualization application for medical imaging shown in Figure 10.7), it is well worth the overhead cost to design for connections in the network, as long as the connection overhead does not result in delays that are greater than the requirements for that application.

Click To expand
Figure 10.7: Example of connection establishment.

A compromise can be made between these trade-offs, and the resulting orientation (either a combination of connection and connectionless or somewhere between connection and connectionless, depending on traffic type, destination address, etc.) may be optimized for the types of flows in the network. There are other trade-offs here, including ambiguity in the routing of flows in the network, as well as a requirement for greater knowledge of flow types within the network.

10.5.2 Technology Functions and Features

Another important design consideration is the set of functions and features that a technology will offer to users, applications, and devices on a network. Some technologies can be used to help the network adapt to specific users, applications, or devices. Examples include adapting to a lack of communications infrastructure, such as in underdeveloped countries, in remote areas where terrestrial access is not easily available, or in environments where traditional access is not possible or is prohibitively expensive; adapting to the portability or mobility requirements of users; or adapting to specific user, application, and/or device requirements, such as in medical, military, or high-end commercial environments.

Whereas some of the adaptability will be provided by the various protocols operating within the network, the technology can also support or enhance this adaptability. Where a communications infrastructure or terrestrial access is not readily available, the use of wireless network technologies, by themselves or in addition to other network technologies, should be considered. In most cases it will be obvious that a communications infrastructure is not feasible and that a nonstandard method of network access is required. Some extreme environments where nonstandard methods of access have been deployed are on research vessels for real-time telemetry, command and control; at disaster areas, such as forest fires, earthquakes, and floods; and at remote, inhospitable places, such as in Antarctica, near active volcanoes, even on the surface of distant planets (in the case of NASA's Sojourner rover).

These examples indicate that network access is possible for a variety of environments, given the right combination of network technologies, services, and protocols, and of course enough funding to deploy and maintain such access.

Similarly, wireless networks can provide support for user portability and mobility, possibly in addition to having multiple network access points available to users. For example, to support users who want access to their network from multiple locations both at work and at home and who also want access from any location within their workplace (via portable computers or personal digital assistants), wireless access would likely be a part of the overall design. Such portability or mobility also affects how users establish connections to the network, as in the dynamic allocation of network addresses or in authenticating users.

When applications and their traffic flows have performance requirements that are predictable, guaranteed, or well understood, we may be able to map their requirements to service levels offered by the technology. We would be able to use the service plan of a flow specification to identify any such requirements and then use these requirements to evaluate candidate technologies. In this case, the technology must be capable of supporting these requirements, which, as we will see, is much more complicated than most people recognize. Such support may range from frame relay committed information rates; SMDS access classes, or their equivalents, to ATM classes of service or IP type of service levels, to combinations of these with resource reservation or allocation mechanisms.

In some instances, some of the behavior patterns of the users and/or applications may be well understood or predictable. When this occurs, the design may be able to take advantage of this by mapping network performance levels to flow characteristics, directions, or patterns. Many flow patterns are asymmetric, with much more information flowing in one direction than the other. This was seen in the client-server, hierarchical client-server, and distributed-computing flow and architectural models discussed in Chapters 4 and 5. When it is expected that a flow will be asymmetric, as in Figure 10.8, we can design the network to optimize the directionality of that flow.

Click To expand
Figure 10.8: Example of asymmetric flows.

Many good examples of this are seen in the usage patterns on the Internet. Web access and use, for example, is predominately asymmetric, with flows toward users. Services are being developed to take advantage of such flow patterns in the Internet, using the asymmetric broadcast capabilities inherent in cable, satellite, and metropolitanarea wireless networks. Hybrid fiber-cable system and xDSL also allow users, both residential and small-to medium-size business, to take advantage of asymmetry in network flows.

When considering the functions and features of various technologies, we need to understand the requirements of the network and how a technology's functions or features will support these requirements, as well as those technologies that will provide a value-added service to the network. In particular, we want to consider distance limitations, locations without infrastructure, users who need portability or mobility, or any way that the environment complicates or constrains the network design.

Distance limitations may force constraints on the delay or RMA characteristics of the network. For example, it will be impossible to guarantee a 40-ms round-trip delay for a flow if the distance is trans-Pacific. This will affect the design in how the communication is provided (e.g., satellite versus cable) or how the flow is modeled (e.g., changing from a hierarchical client-server model to a local client-server model with data migration between regions). We want to look for designs that have long-distance, high-delay communications paths; such designs will create high bandwidth delay products (which describe how much information can be in transit across a network at any given time). Since a high bandwidth delay product means that there can potentially be a lot of information in transit, this requires either large amounts of buffering on the sending side, high reliable connections, good error and flow control, or all of these in the network.

Many designs face infrastructure constraints. If the design includes access to isolated or restricted areas or if mobility is required, use of a wireless technology should be considered.

Value-added services include support services, such as accounting, security, or network management, or may be value added for that particular environment.

10.5.3 Performance Upgrade Paths

Part of the function and feature set of a technology is its upgradability, particularly from a performance perspective. Most, it not all, technologies have evolutionary paths that upgrade performance over time. Typically, performance upgrades focus on capacity but should also include RMA and delay (often in terms of hardware and software latency) when possible. The design process includes considering these upgrade paths and how they may be related to where each technology is located in the network and when they should be upgraded or replaced.

Performance upgrades can be considered from two perspectives: in capacity planning for best-effort flows and in service planning for predictable and/or guaranteed flows. In many networks, both perspectives are taken.

When a technology supports a variety of capacity levels, such as Ethernet at 10, 100, and 1000 Mb/s, and plans to support greater capacity (e.g., 10 Gb/s Ethernet), this information can be used in capacity planning to upgrade areas of the network as individual and composite flows are expected to increase in capacity. As a guideline, capacity increases as flows are aggregated; therefore, the core areas of a network usually require more capacity than the distribution areas, which usually require more capacity than the access areas.

As the numbers of individual and composite flows increase and as flows in general increase in capacity, the capacity requirements of access, distribution, and core networks increase based on the degree of hierarchy in the network. Therefore, upgrade paths are dependent on where they are applied. Often, upgrades are considered in one part of the network (e.g., core) before another in preparation for an upgrade downstream (closer to the users).

Performance upgrades are also applied when predictable and/or guaranteed flows are added to the network. When users, applications, or devices require network resources to be allocated per flow, capacity requirements can increase dramatically with added flows.

Technologies that can use the SONET hierarchy, such as ATM or HiPPI, have a capacity growth path based on selected SONET levels. Each SONET optical carrier (OC) level is a multiple of the base rate, OC-1, at 51.84 Mb/s. This comes from the size of a SONET frame (9 rows by 90 columns) and the clock rate (125 μs), resulting in 8000 frames/s:

(9 rows) × (90 columns) × (1 Byte/row-column) × (8000 frames/s) × (8 bits/Byte) = 51.84 Mb/s

Following are commonly used (or expected) SONET OC levels. When "c" is included in OC-Nc, it refers to a concatenated service, where N SONET payloads are combined in a common frame and transmitted across a common path. Some redundant overhead is removed, resulting in more efficient transmission.

SONET Level | Rate
OC-3 | 155.52 Mb/s
OC-12 | 622 Mb/s
OC-48 | 2.488 Gb/s
OC-192 | 9.953 Gb/s
OC-768 | 39.812 Gb/s

Many factors need to be considered when deciding on an upgrade path for your network. Some of these factors are how dynamic your NICs are (e.g., whether they can support multiple rates, such as 10/100 Mb/s Ethernet), the types and distances of cable runs planned for your infrastructure, and the types of optics (e.g., short-, medium-, or long-reach) optics in your network elements. In addition, some upgrade paths can be accomplished by configuration changes or software upgrades in the network elements, simplifying the upgrade process.

Common upgrade paths include Ethernet from 10 Mb/s to 10 Gb/s, FDDI from 100 Mb/s to 1 Gb/s, ATM and PoS from 1.5 Mb/s to 2.5 Gb/s, and frame relay from 56 Kb/s to 45 Mb/s. Some of these are shown in Figure 10.9.

Click To expand
Figure 10.9: Capacity ranges for selected technologies.

There are also expansions into both higher and lower performance for some technologies. For example, with ATM, frame relay, and SMDS, the capacity range of each technology overlaps that of the others (Figure 10.10). This has had a positive effect on ATM and frame relay and a negative effect on SMDS.

Click To expand
Figure 10.10: Overlap in frame relay/SMDS/ATM capacity ranges.

Performance upgrades should also include any applicable delay and RMA improvements. Delay improvements are likely to be the latency within an individual device that applies the proposed technology—for example, the latency of a switch or router with Gigabit Ethernet interfaces. The latency of individual devices will affect the overall one-way or round-trip delay in the network.

RMA improvement may be either within individual devices or across all devices that apply the technology within the network. For example, RMA may be improved within a device, such as the reliability of a switch or router with a particular technology. RMA may also be improved across all devices of a particular technology, for example, through a protocol or capability that enhances the technology (e.g., technology-specific redundancy software or hardware). For delay and RMA, as with capacity, graphs such as those shown in Figures 10.9 and 10.10 can be useful to make technology comparisons.

As a criteria for technology selection, performance upgrade paths affect the scalability of a network design, based on growth in the numbers of users, applications, and devices, as well as growth in the numbers and capacities of individual and composite flows.

Backbone Flows

Capacity upgrades are particularly important to consider for backbone flows. Backbone flows are the result of aggregating individual and composite flows and are generated where hierarchies are established (e.g., at distribution and core areas of the network). They are more susceptible to growth in capacity, and areas of the network that support backbone flows usually need to be more scalable than areas without backbone flows.

10.5.4 Flow Considerations

Our last evaluation criterion is based on the requirements from existing or expected flows in the network. The flow specification is used as the starting point in evaluating candidate technologies based on the performance requirements of each individual and composite flow.

Flow considerations are any technology-specific capabilities that support or enhance the performance requirements of traffic flows. Such considerations include the ability to recognize and differentiate between flows and apply performance mechanisms identified in the performance architecture component of the reference architecture.

Capacity planning is used to determine the required capacities of candidate technologies. In the next section, we will discuss how to estimate usage and modify flow capacities to reflect this usage. The result will be baseline capacities that we can compare against the available capacities of technologies.

Service planning is also used to evaluate candidate technologies. Each candidate technology will be evaluated on its ability to provide the types and degrees of service support required by the flow specification.


10.6 Guidelines and Constraints on Technology Evaluations

We will be using the information from our flow and requirements specifications to evaluate technologies based on the combined capacity requirements for best-effort services or on the RMA, capacity, and/or delay requirements for predictable or guaranteed services.

In the capacity and service plans of the flow specification, we combined the capacity requirements of all best-effort and predictable services for each flow, and we chose the highest performance RMA and delay characteristics for predictable flows. For guaranteed flows, the individual capacity, RMA, and delay requirements of each flow are used. These RMA and delay characteristics are compared to the ability of candidate technologies to support such services, and the combined capacity requirements are compared with the capacity of each candidate technology. Following are two guidelines for evaluating technologies based on capacity and service plans:

Guideline 1: If predictable and/or guaranteed requirements are listed in the flow specification (service plan), then either the technology or a combination of technology and supporting protocols or mechanisms must support these requirements. This guideline restricts the selection of candidate technologies to those that can support predictable and/or guaranteed requirements.

We can divide this guideline into two portions: support for predictable requirements and support for guaranteed requirements. First, we will examine support for predictable requirements. Recall that predictable requirements provide predictable or bounded performance. The objective of having a predictable service is to reduce the variabilities in RMA, capacity, and delay in network devices so that you can offer a more predictable service to users, applications, and devices. Although determinism in a service results in a better understood and more predictable service, it does not mean that the service is guaranteed to provide a particular level of performance.

What will distinguishing between best-effort and predictable services mean to an operational network that incorporates these design guidelines? Why not just treat all services, including predictable services, as best effort? This is basically saying that all traffic flows are to be treated in a similar fashion—that is, they are all the same, which they most definitely are not. From traffic flows that have no timing requirements (e.g., email), to real-time and mission-critical flows (e.g., telemetry, image processing, and online transaction processing), to interactive-burst flows (e.g., Web applications), each flow type has individual performance requirements that should be supported by the network. Therefore, we must recognize that there are indeed a variety of flows and requirements and service types to support them.

There are a couple of reasons to distinguish between services types. First, by separating those flows that have strict RMA, capacity, and/or delay requirements, we are taking the first steps toward offering multiple, various services to users, applications, and devices. As mechanisms for offering services evolve, becoming better understood and widely available, we will be prepared to take advantage of these services in the network design.

Second, flows that require predictable services need to be handled differently by the network. Given the nature of predictable requirements in flows, they are not as tolerant as best-effort flows to variances in network performance. Thus, we need to ensure that predictable flows receive more predictable performance from the network. This is the basis for our selection of candidate technologies for predictable flows.

For flows that have predictable requirements, we want to choose candidate technologies that can support these requirements. Predictable service is a bounded service, so we want technologies that can provide mechanisms that bound or control performance. Mechanisms to consider come from the performance architecture, for example:

  • Quality-of-service levels in ATM

  • Committed information rate levels in frame relay

  • Differentiated service or integrated service levels in IP

  • Nonstandard or proprietary methods

Such options provide more predictability than traditional best-effort services and can play a part in offering guaranteed services.

Support for guaranteed service is much more stringent than that for predictable services and includes feedback to ensure that the services are being delivered or to provide accountability when service is not being delivered. To offer a guaranteed service, a candidate technology must be capable of:

  • Determining the state of network resources and available levels of performance for the end-to-end path of the traffic flow

  • Allocating and controlling network resources along the end-to-end path of the traffic flow

  • Providing mechanisms to arbitrate and prioritize who gets or keeps service when it is contended for

  • Providing mechanisms to account and possibly bill for service

Note that a guaranteed service is meaningful only when it is applied end-to-end, between well-defined service points. This means that all network devices in the end-to-end path of the flow must provide support for the guaranteed service. As a result, a guaranteed service is the most difficult to provision and operate and will be the most expensive to offer within a network. It is therefore imperative that a guaranteed flow be justified through the requirements and flow analyses before it is considered in the network architecture and design.

For a service to be guaranteed to a flow, the state of each network device in the path of the flow, possibly including each of the end (user) devices, must be determined. There must be some mechanism to keep and provide state information for each of these elements, as well as a mechanism to get this information to make service decisions.

If a guaranteed service is to be offered to a flow, the appropriate network resources will then be configured in each of the network devices in the path of the flow, possibly including each of the end (user) devices. Resources that are configured in the network and user devices include:

  • Buffer allocations, including the establishment of multiple queues and prioritizing traffic flows across them

  • Input and/or output capacity, often linked to buffer allocations

  • CPU usage

In addition, the service needs to determine how to handle periods when there are more service requests than available resources (periods of contention). One method is to offer services on a first-come, first-served basis. Using this method, when the resources are fully utilized, no more service guarantees are given until resources become available. This method is not likely to be used on a large scale, as it promotes holding on to a service as long as possible, even if it is not needed. Another method is to use priorities to determine which flows get service during periods of contention. In this method, a flow may get "downgraded" from guaranteed service to predictable or best-effort service if a higher-priority flow needs the service.

At this time, for guaranteed service, we would consider ATM with its service levels, particularly constant bit rate and real-time variable bit rate for guaranteed capacity. We would also consider integrated services and Resource Reservation Protocol to support guaranteed service at IP. It is expected that vendor support (hardware and software) for guaranteed services will evolve to become more widely available and will be supported in more standard and proprietary technologies.

Guideline 2: When best-effort, predictable, and/or guaranteed capacities are listed in the flow specification, the selection of technology may also be based on capacity planning for each flow. Capacity planning uses the combined capacities from the flow specification to select candidate technologies, comparing the scalability of each technology to capacity and growth expectations for the network.

In the flow specification, we developed capacity estimates for each individual and composite flow. Each of these estimates was based on expected application and user behavior patterns.

When comparing capacity estimates from the flow specification to capacities expected from candidate technologies, we want to determine a capacity boundary that will indicate that a technology's capacity is insufficient for a flow. In capacity planning, we want to design toward that capacity boundary and make sure that the technology has capacity to spare. If the flow contains only best-effort capacities, then a guideline is for the combined (summary) capacity of that flow to be approximately 60% of the capacity boundary for that flow. If the flow contains predictable capacities, then the guideline is for the predictable capacity of that flow to be approximately 80%, or the combined best-effort capacity to be 60%, of the capacity boundary of the flow, whichever is greater.

These guidelines are based on experience and should be used as a first attempt to evaluate technologies based on capacity. As you use them, you should be able to modify them to better approximate your network design. For example, if you can estimate the degree of burstiness in the data flow from an application, you can use it to modify the boundary capacity. Some bursty networks are designed to the boundary capacity divided by burstiness. Thus, if the burstiness (peak data rate/average data rate) of a predictable application is 5, then the design is based on 80% 5, or 16% of the boundary capacity. Doing this enables the network to accommodate a much higher capacity during times of burstiness from applications. To be able to use these guidelines, you need to know the characteristics of each flow in the flow specification.

Table 10.1 contains some estimates for maximum throughput for various technologies. These estimates are from experience, and you should note that these numbers will vary depending on how the network is constructed, the level of maturity of the technology, and the configuration of end (user) devices.

Table 10.1: Throughput Estimates for Selected Technologies

Technology

Maximum Capacity

Maximum Throughput

Ethernet

10 Mb/s

3–9 Mb/s

100 Mb/s

80–95 Mb/s

1 Gb/s

700–980 Mb/s

Token Ring

4 Mb/s

4 Mb/s

16 Mb/s

16 Mb/s

100 Mb/s

80–100 Mb/s

ATM

  • T3

45 Mb/s

34 Mb/s

  • OC-3c

155 Mb/s

120–135 Mb/s

  • OC-48

2.5 Gb/s

2.1–2.35 Gb/s

HiPPI

800 Mb/s

350–750 Mb/s

1.6 Gb/s

0.5–1.4 Gb/s

6.4 Gb/s

1.8–6 Gb/s

Frame relay

45 Mb/s

45 Mb/s

ADSL

Up to 1.5 Mb/s, depending on service level

Up to 1.5 Mb/s, depending on service level

When growth expectations are available, we can use them with the flow specification to estimate scalability for the network design. We may base growth estimates on the numbers of users, applications, and devices in the network.

Technology guidelines are driven in part by what is available from service providers that may be used for the network. For example, if a local service provider can offer only frame relay, you may be constrained to that technology for your network. You may have multiple service providers for your network, with different available technologies (e.g., frame relay, 802.11, cable modem, xDSL). When service providers are coupled to available technologies, you may need to include service providers in your evaluation of these technologies.

Part of the guidelines for technology evaluation should be a requirement to adhere to open technology standards. Open standards are important—they allow the network design to be flexible in adopting the same technology from multiple vendors, helping your customer to be vendor independent. Experience shows that dependence on vendors is usually a problem for customers, locking them into vendor-specific technologies and devices that may not be optimal for the customer.

10.6.1 Constraints on Candidate Technologies

There are three potentially major constraints on the selection of candidate technologies: the costs of each candidate technology, preexisting networks, and implications on facilities.

After developing a list of candidates, we can prioritize the list, much the same way we prioritized the flows in the flow specification. If we already have a cost-prioritized list of flows, we can apply that cost information to the area that the flow is in, as well as to the candidates for that area. For example, let us consider the list in Table 10.2 of cost-prioritized flows (where costs are nonrecurring network hardware and installation for technologies and may include first-year costs for services).

Table 10.2: Prioritized Flows and Candidate Technologies
Composite Flow | Cost (Budget) | Candidate Technologies
BB1 (LAN) | $800K | Gigabit Ethernet HiPPI
F2 (WAN) | $250K | ATM T3 Frame relay T3
F3 (LAN) | $200K | Fast Ethernet 100 Mb/s Token Ring ATM OC-3c
F4 (LAN) | $125K | Fast Ethernet 100 Mb/s Token Ring

For each area (in this case, each LAN/WAN and flow ID [F1, F2, etc.]), we would compare the equipment and installation costs for each technology to the budget allocated for that area. This would either eliminate some candidates or result in a cost-prioritized list of candidates.

When there are existing networks, we will need to consider their characteristics, both the constraints they impose on the design and the features they offer to it. From the flow considerations, the individual and composite flows can be affected when they connect to an existing network. If we have a requirement in the flow specification for a capacity of 150 Mb/s but the flow path traverses an existing Fast Ethernet network, either the requirements and/or flow analyses were not done properly, the existing network technology needs to be upgraded, or the flow cannot be supported by the design. During this evaluation and selection process, analyzing flows that connect to existing networks should identify when an existing network needs to be upgraded or replaced.

Existing networks may support the new design. For example, it may be possible to use existing LAN cabling for faster LAN technologies. Likewise, some WAN technologies, such as ATM, frame relay, or SMDS, may already provide connectivity with existing hardware and may require only a reconfiguration or software upgrade to support a higher-capacity individual or composite flow.

Technology choices have implications on facilities, including requirements to have more available space and sufficient HVAC support. Increases in available space may include space for individual users and their devices, as well as space for devices that are shared, such as servers and specialized equipment.

The purpose of evaluating technologies based on the criteria presented in this section is to help us select a list of candidate technologies to apply to the design. Although a process has been presented here, you will likely want to modify it by adding or eliminating sections. You may also find that one or more of the sections (broadcast and NBMA methods, technology functions and features, performance upgrade paths, or flow considerations) are not appropriate for your network design.


10.7 Making Technology Choices for the Network Design

Now that we have developed some evaluation criteria for candidate technologies, we can begin the process of evaluating candidates for our design. In this section, we will develop some general guidelines for evaluating technologies, with the goal of producing a reasonable number of candidates for each area of the design. Typically, one or two candidates are reasonable. If one candidate is obviously above the rest, then the evaluation process was successful. When there are several candidates (more than two), the evaluation process needs improvement, the requirements and flows have not been sufficiently described, or the candidate technologies are very similar based on the evaluation criteria. When this occurs, you should reexamine the requirements and flows for the design.

In evaluating candidate technologies, we will use the evaluation criteria from the previous section. In addition, we will consider constraints imposed on the selection of technologies, based on cost or the precondition of existing networks. In making technology choices, we will first segment the network into workable sizes. Next we will apply a method that is termed here black box to isolate each area, and then we will apply the evaluation criteria and design guidelines to each area. The result will be one or more technology candidates for each area of the design.

10.7.1 Segmenting the Network

One of the problems we face in designing networks is that they are usually so large that it is difficult to absorb detailed information about the entire design. This is one of the most common complaints about designing a network: where to begin. What is needed is a way to segment the design into workable parts, termed here areas. The area concept that is developed here is similar to routing, addressing, and administrative areas that are used throughout the book. Segmenting the network is the first step toward making the design workable.

There are a few different ways to segment a network. We could segment a network based on geography, concentrations of users, or flow hierarchy. At times, all of these methods will produce similar results, so you should choose the method that makes the most sense and works best for you. Segmenting the network by geography is achieved by decomposing the network into areas whose sizes are based on physical or geographic regions. These regions may range from countries, states, or cities to areas within a city, campus, building, or parts of a building. If a network is being designed to interconnect offices in various cities, one way to segment the network is to divide it into individual city networks (LANs or metropolitan-area networks [MANs]), with a WAN to interconnect them, as in Figure 10.11.

Click To expand
Figure 10.11: Sizing the network design at the (LAN/MAN)/WAN level.

At a campus level, we segment the network into buildings or parts of buildings, such as in Figure 10.12 of a campus network design.

Click To expand
Figure 10.12: Sizing the network design at the campus level.

Similarly, we can divide the network design based on the numbers of users or on relative user concentrations. This may or may not equate to divisions based on geography. Instead of showing geographic information, we describe the numbers of users, perhaps including groups that they belong to within the organization. In Figure 10.13, boundaries are placed between groups of users.

Click To expand
Figure 10.13: Sizing the network design based on user concentrations.

Separating users into groups may be based on where they are located or on some common characteristic. For example, users may be grouped by the organization for which they work.

This method is particularly useful when virtual groups of users are to be supported. Virtual user groups are either groups that are not tied to a particular location or groups that are dynamic in their locations, affiliations, or applications. At this point in the design process we have some flexibility in describing user groups and their user concentrations and in evaluating several methods for supporting virtual user groups, so it is now time to design for these groups. In doing so, we can optimize the design for them.

Arguably the most useful way to segment the network is by flow hierarchy. This method uses information in the flow specification to show where potential hierarchies may exist in the network. In addition, this method has the benefit of showing flows and their requirements, which will be important when evaluating and applying technologies to the design. Consider the flow hierarchies of a flow diagram such as those shown in Figure 10.14.

Click To expand
Figure 10.14: Sizing the network design based on flow hierarchies.

Here we can use the locations where individual and composite flows meet as boundaries for areas. In Figure 10.14, we placed boundaries at five locations, resulting in six network areas. Note that we also used performance templates (Ta, Tb, Tc, Td) to simplify showing performance requirements. When multiple flows have the same requirements, they are represented by the same performance template.

In a sense, segmenting by flow hierarchy incorporates geographic and user-group methods. Since flows are end-to-end between users, applications, and devices and their requirements have location information built into them, geography and usergroup information make up part of the flows.

The goal of segmenting a network is to decompose the network into areas whose sizes are small enough to limit the amount of information in choosing technologies, thus making technology selection easier. This means that the numbers of users, applications, devices, flows, and potential connections outside of the area are small enough that it is possible for a single technology to reasonably support that area. This requires an understanding of how various technologies size and scale. As you work through this chapter, you will find that segmenting the network overlaps with evaluating and applying network technologies.

Some related parameters for segmenting your network include the sizes of broadcast domains, types of services requested by users, and performance requirements of flows in the network. A broadcast domain is a group of network-addressable devices that can be reached by a single network address, the broadcast address. As a broadcast domain increases in size or as the number of broadcast protocols operating in a domain increases, the amount of broadcast traffic increases, affecting the overall performance of the network. It is desirable to keep the size of a broadcast domain reasonably small, especially if growth in the size of the network is expected.

An Alternative Method for Segmenting Networks

One method to segment networks that is often used in the field is to base the segmentation on functions and features required in that network. For example, WANs have some distinguishing characteristics that separate them from LANs (besides distance). A WAN may incorporate service providers and local and interexchange carriers that will affect its design. Likewise, there are locations in designs where many flows converge. These locations can have characteristics similar to Internet network access points (NAPs).

This method of segmenting leads to five types of areas in the design (Figure 10.15): WANs, which often use service providers and are focal points for flow consolidation; NAPs, which interconnect and integrate (or separate) the other areas; specialized areas, which have requirements and flows that dictate particular technologies; backbone or core areas, where flows are consolidated for transport; and general areas, which focus on more traditional requirements and where capacity planning, scalability, and cost-effectiveness are primary considerations. This method is offered as a simple, workable hybrid of the other methods. You should consider this method, as well as the other methods presented in this chapter, as a start toward developing your own method to segment networks.

Click To expand
Figure 10.15: Sizing the network design based on functions and features of each area.

Segmentation can sometimes be used to solve security compartmentalization problems. Segments that need a higher degree of security can sometimes be isolated and a firewall can be used to provide the necessary protection. Segments isolated by security may be indicated during the development of the security architecture.

10.7.2 Isolating Areas—The Black-Box Method

With the network segmented into areas, we are ready to make technology selections for each area, after which the areas will be integrated into the design. As mentioned earlier in this chapter, one of the challenges in doing network design is being able to focus on a subset of the design. Some network designs are so large that it is easy to get lost within the design

The black-box method is a way to isolate each area of the network, making the technology selection process easier. This method hides areas of the design that we do not wish to focus on, isolating the area of choice. In this sense, it is similar to the traditional notion of a black box in engineering, where everything inside the black box is hidden from view.

This method can be applied in two ways: using a black box to cover the area under review and using it to cover everything else. In the first method, a black box is applied to the area where technology choices are to be made. When the black box is applied, only the inputs to and outputs from the black box are shown (Figure 10.16).

Click To expand
Figure 10.16: A black box isolates the inputs and outputs of each area.

In Figure 10.17, the inputs to and outputs from the black box equate to the flows and flow information for the area under review. With this method, the black box is applied to a particular area, technologies evaluated and chosen for that area, and the black box is moved to the next area. This process is repeated until technology choices are made for each area of the network design.

Click To expand
Figure 10.17: Black box applied to area under review.

The second method is to apply one or more black boxes to areas of the network design that are not under review. This allows visibility into the area under review while all else is blocked out (Figure 10.18).

Click To expand
Figure 10.18: Black box applied to areas not under review.

As can be seen in Figure 10.18, this method blocks out the rest of the network design but leaves the area under review open to inspection. Although both methods have been used in the field, the first method (applying the black box to the area under review) is predominantly used.

We can use the black-box method at any level in the network design to hide the entire network (e.g., hiding existing networks), one or more areas or parts of areas, geographic or topological features (e.g., regions of a country, a campus, a building), even network devices in existing networks. At the extreme, a black box can hide everything except a single network device (e.g., router or switch), or it can be used only at the edges of the network design, leaving everything else within the network design exposed. Black boxes are applied to each area of the network design and are moved from area to area, until technology selections have been made for the entire design.

The black-box method, like other tools described in this book, is presented to help you in your design process. You may find it helpful, even necessary, to apply this method in large-scale network designs, although it may not be needed in smaller designs.

10.7.3 Applying Evaluation Criteria and Guidelines

As each area of the network design is isolated with the black-box method, we apply all of the information we have gathered, derived, and developed so far to make technology selections for the area. This information includes the variety of user, application, device, network, and other requirements; maps of location-specific information; flows and the flow specification; architecture and design goals; architecture information for each component architecture and the reference architecture; technology evaluation criteria; and guidelines.

How you apply all of this information depends primarily on what you have selected as your design goals, as well as how these design goals translate into evaluation criteria. The clearer your evaluation criteria are, the easier it will be to apply them to the design.

As you proceed through this process, making technology selections for each area of the design, you will find that different areas of the design may require different technologies. It is important to keep the design fairly homogenous in terms of network technologies. If too many technologies are chosen for the design, interoperability problems will arise. Therefore, as you move from area to area making technology selections, whenever you make selections that are different from previous areas, consider reevaluating previous areas to keep the number of selections low. At times, you may not be able to avoid having several technologies present in the design; however, limiting the number of technologies is suggested to keep the design simple and easy to implement.


10.8 Conclusion

In this chapter, we discussed the process of selecting network technologies for your design. There are numerous sources of information that you can use in this process, information that you have gathered, derived, and developed as part of the analysis and architecture processes. This information—including user, application, device, and other requirements; maps of location-dependent information; flows and the flow specification; architectural and design goals; design criteria; and guidelines—will be helpful in making technology selections. In particular, developing a set of design goals and evaluation criteria is critical to making technology choices.

In this chapter, we also discussed how to segment the network into areas, based on geography/topology, flow hierarchies, or user concentrations, and how to focus on each particular area using black boxes to conceal details of selected areas.

Although this book attempts to be vendor independent, a listing of potential vendors may need to be included in the technology selection process. As you proceed through the design process (and on into procurement and implementation), technology selection will evolve into product selection. Technology selections that start as vendor independent will evolve to incorporate vendor information, even if it is nothing more than potential vendors of that technology.

Having made technology selections for our network, we will learn in the next chapter how to interconnect these technologies, thus bringing the network design together.


10.9 Exercises

  1. For the following primary design goals, list at least two secondary or derivative design goals. Explain your answers.

    1. Minimizing WAN costs

    2. Simplifying network management

    3. Maximizing supportability

    4. Scaling the network

      1. From LAN to WAN

      2. To double its backbone capacity

      3. To increase the number of users by 50%

  2. A particular LAN network design has design goals of making the network easy to use and administer and maximizing the performance of the network by choosing the highest-performance technologies available.

    1. Explain possible trade-offs between these two design goals.

    2. Develop a simple chart that shows that trade-offs in (a) for the following technologies:

      1. Ethernet (10bT)

      2. Fast Ethernet

      3. Gigabit Ethernet

      4. FDDI

      5. ATM OC-3c

      6. ATM OC-12c

    3. Describe the requirements for network management for each of the technologies in (b), including help-desk or network operations center support.

  3. Some common technology evaluation criteria are discussed in Section 10.5 and are shown below. Apply these evaluation criteria to the list of technologies in Exercise 2b.

    Technology

    Broadcast Support

    Connection Support

    Technology Functions and Features

    Performance Upgrade Paths

    Flow Considerations

  4. List two other evaluation criteria in addition to those described in Section 10.5. Apply these additional evaluation criteria to the list of technologies in Exercise 2b.

  5. Describe how black boxes are used to isolate areas of a network. Apply this method to the network in Figure 10.19. Show how black boxes are applied to hide each area under review and to hide the other areas.

    Click To expand
    Figure 10.19: Network for Exercise 5.

  6. In Figure 10.20, you are asked by the customer to make technology decisions for this network. Determine the placement of black boxes in each area to prepare to make these decisions.

    Click To expand
    Figure 10.20: Network for Exercise 6.


Chapter 11: Interconnecting Technologies Within the Network Design

Having made technology selections for the network design in Chapter 10, we complete the design process by connecting these technologies together within the network design. Methods to connect technologies (interconnection strategies), in conjunction with the technology choices made in the previous chapter, provide detail to the design in preparation for planning and installation.

11.1 Objectives

In this chapter, you will learn about interconnection strategies, particularly switching and routing. We will discuss in detail how switching and routing work, compare and contrast their characteristics, and determine where each strategy should be applied within the network.


11.2 Preparation

To be able to understand and apply the concepts in this chapter, you should be familiar with the fundamentals of connecting technologies together, including switching and routing. Some recommended sources of information include:

  • Interconnections: Bridges, Routers, Switches, and Internetworking Protocols, 2nd edition, by Radia Perlman, Addison-Wesley Publishing, October 1999

  • ATM Solutions for Enterprise Internetworking, 2nd edition, by David Ginsburg, Addison-Wesley Publishing, June 1999

  • SONET, by Walter Goralski, McGraw-Hill, May 2000

  • MPLS: Technology and Applications, by Bruce Davie and Yakov Rekhter, Morgan Kaufmann, May 2000

  • Switched, Fast, and Gigabit Ethernet, 3rd edition, by Sean Riley and Robert Breyer, New Riders Publishing, January 1999

  • The Switch Book: The Complete Guide to LAN Switching Technology, by Rich Seifert, John Wiley & Sons, June 2000


11.3 Background

Having made technology selections for each area of the network design, we can now focus on mechanisms that connect these technologies to each other within the network and optimize the overall design to achieve our design goals. These mechanisms, termed here interconnection mechanisms, bring the design together.

At this point in the design process, we have a number of technologies that have been chosen for the network. There are also network devices, such as routers, switches, multiplexers, servers, and hubs, where these technologies are applied. What we do not know yet is how these network devices and the technologies applied at each of them are connected together. Figure 11.1 shows multiple technologies and the network devices that implement them. These devices and technologies are not connected.

Click To expand
Figure 11.1: Technology selections and network devices need to be interconnected to complete design.

In understanding, choosing, and applying interconnection mechanisms, we determine how these technologies and network devices are connected (Figure 11.2). Although this seems obvious and (possibly) quite simple, it is actually an important and subtle component of the network design. The selection of interconnection mechanisms affects all architectural components (addressing/routing, network management, performance, and security), as well as the traffic flows determined in the flow analysis process.

Click To expand
Figure 11.2: Technology selections and network devices when connected.

Figure 11.2 represents the interconnection of network devices and technologies. Each arrow is an instance of an interconnection mechanism. Arrows between Technologies A, B, and C represent the interconnection of these technologies, although they would actually be interconnected through their network devices. For example, Technologies A, B, and C would be interconnected via the switches and routers that have their technologies in common.

Interconnection mechanisms include using a shared medium, where all hosts are on the same network or subnetwork and there is no interconnection to other network technologies, various types of bridging (e.g., Ethernet/ATM/frame/IP/wavelength), and routing. Interconnection mechanisms are applied predominantly at the link or network layer but can be found at any layer in the protocol model.

Some interconnection mechanisms are hybrids of switching and routing. They attempt to combine both mechanisms to optimize performance at both the link and the network layer. Part of optimizing performance includes being adaptable to existing technologies and allowing for the creation of virtual networks (e.g., VLANs, virtual private networks [VPNs]). Hybrid mechanisms include LAN emulation (LANE), multiprotocol over ATM (MPOA), the Next-Hop Resolution Protocol (NHRP), multiprotocol label switching (MPLS), and switching based on flow or end-to-end information.

Despite what some vendors may tell their customers, there is no all-encompassing, "right" mechanism. Each mechanism described earlier has its advantages and disadvantages, and each can be successfully applied to network designs. Your job, as a network designer, is to determine which is best for your design based on what you have already done, the analysis, architecture, and technology selection for your network.

Understanding interconnection mechanisms can be somewhat tricky as they evolve and incorporate each other's features. Routing and switching are being integrated through mechanisms such as MPLS to optimize performance, at the trade-offs of complexity and cost, for some networks. The trend in interconnection mechanisms is toward convergence at the link and network layers. The separation of functions and features at each layer is being lost, resulting in a lot of options, and making solutions harder to understand by everyone. Instead of having several network devices that perform a specific function (e.g., routing), network devices now integrate several functions and features into one box.

Figure 11.3 provides the open-systems interconnect (OSI) seven-layer model to reference where the data-link and network layers are located relative to the other layers.

Application

Presentation

Session

Transport

Network

Data Link

Physical

Figure 11.3: OSI seven-layer model.

This integration of link-and network-layer functions is not necessarily good or bad, just different from what we are used to working with. As long as we can maintain some clue about what each mechanism does and what the trade-offs are between them, we can make them useful in the network design. A goal of this chapter is to examine these mechanisms from several perspectives so that you can understand their functions, features, and trade-offs.

As you proceed through this chapter, you will see that there are many reasons for planning routing, switching, bridging, and hybrid mechanisms in a network design. There are also designs in which a shared medium with no interconnections is warranted. We will discuss several factors in evaluating interconnection mechanisms, including supporting scalability of the network, optimizing flow models, providing external connectivity to the network, and applying support service to the design.

We begin with the simplest interconnection mechanism, consisting of no interconnection at all, a shared-medium mechanism.


11.4 Shared Medium (No Interconnection)

A shared-medium mechanism is when all devices on the network (or subnetwork) share the same physical medium. When a shared-medium mechanism is applied to areas of a network design, the areas are combined to form a larger version of an area network. Figure 11.4 shows an example of this.

Click To expand
Figure 11.4: Interconnecting multiple Ethernet segments using a shared-medium mechanism.

In Figure 11.4, Ethernet has been chosen for two areas of a network design. By making these areas, each of which has its own Ethernet network, shared medium, we have combined them into one larger Ethernet network. This is done by directly combining the networks through physical connections or repeaters. The result is that the combined areas all share a common broadcast domain at the link layer and a common IP addressing structure at the network layer.

Although this is the simplest interconnection mechanism, it has major trade-offs, primarily the lack of scalability. As the numbers of devices on a shared-medium network grows, so does the overhead associated with multicast, address-resolution, and network-layer functions. This overhead can degrade network performance and cause congestion that will make the network unusable. As a result, hierarchy forms to isolate parts of the network from each other. When does this hierarchy form, and when should we plan to expect or provide hierarchy in the network? To answer these questions, we need to consider scalability, flow model optimization, and external connectivity.

In Chapter 10, we looked at scaling the network based on the growth in users, applications, and devices. Scaling was achieved by selecting candidate technologies that could either handle the expected growth in capacity or had planned upgrades to meet the expected increase in capacity by the time it was expected. Another way to meet growth expectations is to plan for hierarchy in the design.

Planned hierarchy is integrating into the network design methods to isolate and hide networks and their traffic from one another. Planned hierarchy can be accomplished over time by adding new networks to the design or segmenting existing networks, as in Figure 11.5.

Click To expand
Figure 11.5: Planning hierarchy in the network design.

When hierarchy is added to a shared-medium network, the shared medium is segmented and interconnected by bridges, routers, switches, or hybrid devices. The guidelines for capacity planning developed earlier for scaling networks can be applied here, with slight modifications, to show when hierarchy needs to be introduced into the shared-medium network:

  1. When the maximum (peak) rate for expected traffic flows on a shared-medium network approaches 80% of the capacity for the technology used in that network

  2. When the sustained data rate for expected traffic flows on a shared-medium network approaches 60% of the capacity for the technology used in that network

In these guidelines, traffic is the statistical sum of all application, user, and device information flows over that network. This is determined by either sampling the flows over the network (if there are existing networks or testbed networks where this can be done); using existing information from traffic studies; or estimating the traffic based on each application's peak and/or sustained data rates, percentage utilization of that application on the network, and number of simultaneous sessions of that application.

Given that many of today's applications and devices can easily reach the maximum capacity of many network technologies, including Fast Ethernet and ATM/OC-3c, planning to introduce an interconnection mechanism to segment a shared-medium network is worthwhile. This is true even when the peak and sustained data rates for applications on that network are low relative to the capacity of the shared-medium network.

A requirement for a high degree of interconnectivity is also an indication of the need for an interconnection mechanism. The higher the degree of interconnectivity (the degree of connections within the network at different levels in the design, to provide greater performance through parts of the network) is within a network, the greater is the need for an interconnection mechanism that can rapidly reroute traffic. When we apply interconnection mechanisms to the design, we will use degrees of interconnectivity to determine when and where to apply them.

A shared-medium mechanism is typically not optimal for the flow models described in Chapter 4. When client-server, hierarchical client-server, or distributed-computing flow models are indicated in the design, we should automatically consider an interconnection mechanism for that part of the design. As discussed in Chapter 4, these flow models have characteristics that are optimized by creating a separate path for each flow.

When external connectivity is expected, an interconnection mechanism must be added to the design. When connectivity is to the Internet, the interconnection mechanism must be IP routing or a protocol gateway.

Interconnection mechanisms are closely tied to security, administration, and network management. These functions are often co-resident with interconnection mechanisms. As we will see later in this chapter, the mechanisms selected for interconnecting networks will play a role in how security and network management are implemented.


11.5 Switching

Switching is forwarding information (e.g., cells, frames, packets) between segments of a network or subnetwork. This is usually done at the link or network layers but may occur at any layer in the network. For example, wavelengths of light can be switched at the physical layer in dense or wide wavelength division multiplexing (d/wWDM) networks. Bridging can be considered a subset of switching, typically applied at the link layer. There is an old statement "bridge when you can, route when you must" that can be modified to "switch when you can, route when you must." However, as we will see, routing is a vital interconnection mechanism that should be considered along with switching.

Switching can be viewed as a relatively simple way to achieve scalability and to optimize some flow models. Switches are a good choice when the network design is simple and the speed of switching is required. As the design becomes complicated (e.g., large amounts of growth expected, crossing administrative boundaries, connecting to other networks, a requirement to accommodate diversity in media or technologies), routers offer network-layer interconnectivity to help with this complexity. From this perspective, switches can be thought of as a first or intermediate step in interconnecting networks, leading to routing as the complexity increases.

When switching is required to support scalability in a design, you can use the capacity planning guidelines to determine at what point it will be needed. Switching can also be used to optimize flow models, particularly client-server, hierarchical client-server, and distributed-computing models. Switching helps optimize these models by supporting multiple concurrent traffic flows at media speeds through the switch. When a model indicates that there will be multiple concurrent flows, switching should be considered at the points where these flows converge. Consider, for example, a network segment to which the distributed-computing model applies, as in Figure 11.6.

Figure 11.6: Flows in a distributed-computing model.

The flows in this network segment are between neighbor computing devices and have strict performance requirements. Instead of having these flows share the same physical media, they can be interconnected with one or more switches (Figure 11.7), isolating the flows and reducing the required capacity across any particular media segment.

Click To expand
Figure 11.7: Distributed-computing flows with a switch applied.

For example, in Figure 11.7, flows marked "a" are localized to a switch interface, and flows marked "b" are forwarded between interfaces. Whereas all flows in the shared-medium network are forwarded over the same physical network, the switch allows multiple concurrent flows to be forwarded over different physical interfaces, improving performance. When the network segment is local, such as in computer room, building, or campus environments, a switch provides a simple, fast, and cost-effective solution to handle multiple concurrent flows. Although a router could also be used in these situations, it can be a more complex solution.

If the aforementioned distributed-computing example was extended across a WAN, the end-to-end delay and capacity characteristics across the WAN, as well as possible requirements for external connectivity (e.g., connecting to a service provider), security, and network management, may be better satisfied with routers, as shown in Figure 11.8.

Click To expand
Figure 11.8: Routing distributed-computing flows across a WAN.

For this network segment, switches will optimize the performance of flows within each switch-local computing group and routers provide performance, as well as security and management support across the WAN. If there were any differences in the delay characteristics of switches and routers used in this network, they would likely be masked by the end-to-end delay characteristics of the WAN.

In this chapter, we will discuss some of the important characteristics of switching at the physical, link, and network layers.

11.5.1 ATM Switching

There has been a great deal of debate about where ATM is most useful, in the backbone or the core network, in the WAN, or at the access network, directly to the desktop. When ATM first hit the general networking world (for many people, at the 1992 Interop conference), it appeared the probable successor to existing technologies. Some even predicted that ATM would replace IP. It did have a serious impact on switched multimegabit data service and appeared to threaten frame relay, Ethernet, Token Ring, and fiber distributed data interface. There has been some backtracking since then, reducing the scope of ATM to network backbones and WANs. This is partly due to the inherent complexity and overhead of ATM, the lack of large operational ATM networks (relative to the number of new networks based on existing technologies), and the slow growth in services-based networking. What then are the roles of ATM today and in future networks?

It is important to note that a reduction in the scope of ATM networks should have been expected. Proponents of ATM tried to accomplish quite a bit in a short period, for a variety of reasons. But this does not mean that they were heading in the wrong direction. What many network architects, designers, and developers have known for a long time is that each technology, service, and interconnection mechanism has its purpose and no single one is the "right" answer. Like the home builder who has a variety of specialized and general tools or the software developer who relies on many different algorithms, techniques, or specialized code fragments, network architects and designers use various network technologies and interconnection mechanisms and it is good practice to be able to use all available tools and to know where and when to apply them. ATM is no exception.

ATM can be used in backbone networks, in WANs, and in the access network to the desktop, depending on the requirements of the network. This is where the requirements and flow analyses, as well as the component and reference architectures, can give some insight into the design, specifically in identifying where each tool (such as ATM) may be applied. In addition to requirements, flows, and architectures, we need to understand the trade-offs of using ATM and its implications to desktop, backbone, and WAN networks, particularly if it is applied end-to-end between applications.

There are some general trade-offs with ATM. One is the ability to support end-to-end services versus added complexity. Another is perceived high performance versus overhead.

ATM can provide support for end-to-end services, and requirements for this support are growing. As we saw at the beginning of this book, services are an integral part of the system and are evolving as a requirement in some networks. However, services can add complexity to the network design. For example, to support service end-to-end between users, applications, or devices, state information has to be kept about the traffic flows using that service, characteristics of the services themselves (including performance), and network resources requested and provided. Services to different flows are likely to be merged within the network (this should be evident in the flow analysis), and this merging has to be managed by the network. The dynamic nature of data networks implies that flows will be interrupted, halted, reestablished, and rerouted along different paths, and any state information associated with these flows will need to be learned by network devices along any new paths for the flows. The process of learning state information for flows as they move through the network is resource intensive.

Although the cost of complexity can be high for ATM, the potential benefits can be great. Supporting service and performance end-to-end through the network may be the only (or best) way to support emerging applications. As this generation of services-based networking matures, end-to-end service and performance will be a distinguishing feature of successful networks.

ATM can also provide high levels of capacity, and the combination of ATM and synchronous optical network (SONET) gives a known path for performance upgrades. ATM is supported at various SONET optical carrier (OC) levels (including concatenated service): OC-3, OC-12, OC-48, and OC-192. There is capacity overhead associated with ATM, as with all technologies and protocols, but it is relatively high with ATM. This is due to its small, fixed cell sizes and segmentation and reassembly (SAR) functions. At 53 bytes, with 5 bytes of header and 48 bytes of data, the initial overhead is 5 (53, or 9.4%. When SAR and ATM adaptation layers (AALs) are included, this overhead can grow to 5 bytes of header and 8 bytes of AAL, or (5 + 8)/53 = 24.5%. And this does not include the overhead from SONET or other protocols.

Example 11.1: Protocol Overhead Analysis
Start example

An example protocol overhead analysis for SONET, ATM, AAL5, and Ethernet bridging using RFC 1483 (also known as 1483 or LLC/SNAP) is presented. When all of the protocol overheads are added up, it is a significant portion of the overall capacity of an OC-3c link. Protocol overhead is important to understand when choosing interconnection mechanisms in that it affects the overall performance and efficiency of the network.

Each protocol layer adds overhead, by encapsulating higher-layer protocols with header and trailer information. This section estimates protocol overhead at various places in the network. Based on studies of Internet traffic flows (see vBNS reports at www.caida.org or ee.lbl.gov for more information), most traffic flows are less than 1000 bytes in size, with local maximums at around 64 and 560 bytes. For this protocol overhead analysis, we will use 556 bytes for the traffic (data) flow size. This corresponds to a commonly used maximum transmission unit (MTU) size of 576 bytes (with TCP header added). This data size also includes any protocol overhead from the application.

At the users' access network, various protocols are added to the traffic flow. The following encapsulations are applied, starting with the transport layer. At the transport layer, TCP adds 20 bytes of overhead. This overhead consists of port information, sequence numbers, TCP window information, and a checksum. The protocol overhead of TCP is 20 bytes ÷ 556 bytes, or 3.60%.

Click To expand

At the network layer, an IP header is added. This header adds another 20 bytes of overhead, consisting of Version, Length, Type of Service, Fragmentation, Flags, and IP address information. The IP header brings the overhead to 40 bytes ÷ 556 bytes, or 7.19%.

Click To expand

Since the user is sending and receiving traffic, the PPP and PPPoE sessions are expected to be established and at steady state. Steady-state PPP adds 2 bytes of protocol type information when used with PPPoE. This brings the total overhead to 42 bytes ÷ 556 bytes, or 7.55%

Click To expand

The PPPoE header provides Version, Type, Code, Session ID, and Length information, adding a minimum of 6 bytes as header. More information, in the form of PPPoE TAGs, may be added; however, it is assumed that the PPP/PPPoE session is steady state and not using TAGs to modify the session. With an additional 6 bytes of overhead, the total overhead is now 48 bytes ÷ 556 bytes, or 8.63%.

Click To expand

At this point, the Ethernet encapsulation is added, with its 12 bytes of source and destination addresses, 2 bytes of protocol type, and 4 bytes of checksum. This increases the overhead by 18 bytes, so the overhead is now 66 bytes ÷ 556 bytes, or 11.87%.

Click To expand

This is the amount of encapsulation that user traffic will encounter across the network. For a flow of 556 bytes, all of the flow can be encapsulated in a single Ethernet frame (which can accommodate up to 1500 bytes of subscriber data), with 66 bytes of TCP, IP, PPP, PPPoE, and Ethernet overheads. This analysis does not consider any padding that may occur at some of the protocol layers, such as for PPP.

More protocol encapsulations occur as data enter the SP Backhaul network. With 1483 encapsulation, used to bridge Ethernet frames across an ATM network, 12 bytes of overhead is added, making the total overhead for a 556-byte flow 78 bytes ÷ 556 bytes, or 14.03%.

Click To expand

The 1483 frames are passed to AAL5, where 8 bytes of AAL5 information is added. The resulting frame must be a multiple of 48 bytes (the size of an ATM cell payload), so padding is added to bring the frame to the appropriate size. For the example flow, the 1483 frame size is 634 bytes + 8 bytes of AAL5 information = 642 bytes. This is not an integer multiple of 48 bytes, so 30 bytes of padding is added to bring the frame to 672 bytes, which equates to fourteen 48-byte ATM payloads. The resulting overhead for this flow is now 78 bytes + 8 bytes (AAL5 information) + 30 bytes (padding) = 116 bytes, which is 116 bytes ÷ 556 bytes, or 20.86% total overhead.

Click To expand

ATM header information, consisting of 5 bytes of ATM addressing, payload type, priority, and checksum, are added to each of the ATM payloads. For the 14 ATM cells, the ATM overhead is 5 × 14 = 70 bytes, and total overhead is now 186 bytes ÷ 566 bytes, or 33.45%.

Click To expand

ATM cells are transported as either DS3 or SONET OC-3c payloads. For DS3 with PLCP framing, 12 ATM cells are inserted into a PLCP frame, with 48 bytes of PLCP information and 12 to 13 nibbles of trailer. For the 14 ATM cells in the flow, two PLCP frames will be needed. Assuming that no other traffic flows will be inserting ATM cells into the second PLCP frame and that a 12-nibble (6 byte) trailer is used, the PLCP overhead will be 2(48 + 6) = 108 bytes. The total overhead for all protocol encapsulations—TCP, IP, PPP, PPPoE, 1483, AAL5, ATM, and DS3—is then 294 bytes ÷ 556 bytes, or 52.88% for a 556-byte flow.

Click To expand

ATM cells can also be transported via SONET, using an STS-3c SONET payload envelope (SPE) and OC-3c frame. SONET has three types of overhead: section overhead (SOH), line overhead (LOH), and path overhead (POH). SOH, LOH, and POH use 81 + 3 × 9 = 108 bytes of the 2430-byte OC-3c frame. If there are no other traffic flows that contribute to the SPE, then the SONET overhead is 108 bytes. The total overhead for all protocol encapsulations—TCP, IP, PPP, PPPoE, 1483, AAL5, ATM, and SONET—is then 294 bytes ÷ 556 bytes, or 52.88% for a 556-byte flow.

Click To expand

Other interesting traffic flows that should be considered here include small (16 to 64 kb/s) voice over IP (VoIP) flows, large (4 KB or greater) TCP flows, and User Datagram Protocol (UDP) flows of various sizes.

End example

ATM options focus on interconnecting ATM with traditional technologies and providing (what is traditionally) network-layer functions with ATM. LANE can connect other LAN technologies together, such as Ethernet and Token Ring, as well as connecting them to ATM networks. LANE emulates the broadcast environments of Ethernet and Token Ring across the ATM network. To accomplish this, it provides support for the characteristics of these technologies, including address resolution, broadcasting, and their connectionless nature. To the network layer, emulated LANs appear as a bridged network.

There are three mechanisms to introduce LANE into a network design. First, it can be used to introduce ATM into a backbone or a core network while minimizing the impact to users by not making changes to their device configurations or network interface cards (NICs). This can be quite important in a network that has a large existing base of devices with Ethernet and/or Token Ring NICs. Second, it can be used as an intermediate step in migrating to other ATM options, such as 2225 (based on RFC 2225, formerly RFC 1577) networking, native ATM, NHRP, or MPOA. By introducing ATM into the backbone via the first mechanism, we can migrate devices from LANE to another ATM mechanism. Third, we can use LANE to tie together groups of Ethernet or Token Ring devices, as a permanent solution when the devices do not need more than Ethernet or Token Ring connectivity or performance.

A major reason for using LANE is to keep existing Ethernet and Token Ring networks, as well as their associated NICs, in place. This saves on the investment of these NICs, which can be a substantial portion of network expense. ATM can be brought into a network, for example, as a backbone technology, and LANE used to connect devices as Ethernetor Token Ring-attached devices. In this way, LANE can help minimize the impact of network modifications to users.

However, these benefits come at a cost. A trade-off in being able to capitalize on an existing investment in the traditional technologies by using LAN as an interconnection mechanism is in the increased complexity of the network. LANE emulates Ethernet and Token Ring networks, and the mechanisms used to provide this emulation can result in events on the network that are often difficult to understand or solve. This is primarily due to added components, such as LAN emulation clients (LECs), LAN emulation servers (LESs), LAN emulation configuration servers (LECSs), broadcast and unknown servers (BUSs), and special multicast servers (SMSs). Other complexities include the virtual-circuit connectivity between components and the resulting ambiguity in the underlying infrastructure. Thus, more knowledge about the structure, state, and behavior of the network is required for proper operation. Such knowledge can be provided through the use of LANE-specific network management software and hardware or through skilled, specialized network staff.

On the other hand, being able to continue to use existing networks while integrating ATM into the backbone or WAN can save substantial amounts of time and money while allowing those who will operate and manage the network to use their existing knowledge of traditional technologies. Therefore, if a design has a significant number of existing networks based on Ethernet and Token Ring, LANE should be one of the considerations as an interconnection mechanism, with the caveat that there will be complexity and cost in terms of required LANE and network-knowledgeable staff.

These trade-offs can be applied to the design goals discussed earlier. If a primary design goal, or evaluation criterion, is minimizing costs for the network, then LANE will be an option if you have a large base of existing Ethernet-and Token Ring-attached devices. If the primary goal is maximizing ease of use and manageability of the network, LANE is less clear as an option; although it will provide ease of use to users, since their interfaces to the network will look the same, manageability of the network will likely be more difficult with the added complexity of LANE. When network performance is a design goal, LANE can be seen as an intermediate step in improving performance for users and their applications and devices. If users were previously on a shared Ethernet, LANE can improve their performance but will not improve performance beyond switched Ethernet or Token Ring performance. Where LANE can make a difference is in the backbone network, as we can bring in a highperformance backbone (e.g., at OC-3c or OC-48c) and attach devices with LANE and then migrate them as needed from LANE to either a direct ATM connection or another high-performance technology (e.g., Gigabit Ethernet, high-performance parallel interface [HiPPI], or fiber channel) connected to the ATM backbone.

Classical IP over ATM networks, based on the specifications of RFC 2225, interconnect networks via ATM and IP in a more straightforward albeit IP-centric fashion. RFC 2225 networks treat ATM as another underlying technology for IP, and interconnections are done with routing. This is changing, as with LANE, by having the option of a cut-through path as the ATM layer. A trade-off in RFC 2225 networking is not taking full advantage of ATM, along with its potentially strange interconnectivity patterns, versus the simplicity of interconnecting at IP.

RFC 2225 does not take full advantage of the switching and service capabilities of ATM but instead forces ATM to mold itself to an IP structure. If your existing network or your network design is based on a large IP network, then changing IP addressing, routing, and structure may be difficult. Starting with RFC 2225 can be an intermediate step toward integrating ATM into such networks and can be used in conjunction with a plan to migrate from RFC 2225 to another mechanism that takes greater advantage of ATM. RFC 2225 can be useful in areas in which multiple technologies meet, such as at backbones or enterprise-level NAPs.

In Figure 11.9, three logical IP subnets (LISs) are configured over a common ATM network. Recall the behavior of IP networks from our discussion of the basics of IP (at the beginning of this chapter). For each LIS, all hosts and routers must be able to connect to each other, and traffic between LISs must be sent to a router between them. The scalability of ATM is reduced in this environment, unless broadcast and address resolution mechanisms are added to the network. Basically, ATM provides the link-layer infrastructure for an IP subnet, and traffic flows between subnets are routed. This can result in strange traffic flows when multiple LISs are built on a large-scale ATM infrastructure. For example, if LISs cross a WAN, flows that would normally stay within a LAN may cross the WAN to be routed (Figure 11.10). In a situation like this, it is clear that a direct-switched path is preferable to the longdistance-routed path.

Click To expand
Figure 11.9: ATM in a classic IP network.
Click To expand
Figure 11.10: Example of suboptimal flows in classic IP over ATM.

Although there are times when ATM switching is optimized over routing in this example, it is not permitted. If a cut-through path is allowed, however, RFC 2225 begins to look more like NHRP or MPOA in its behavior.

A key benefit to a strictly IP-interconnected design is that IP is relatively well understood. Since ATM is treated as yet another link-layer technology, any reliance on ATM for interconnectivity is minimized. This makes it easier to replace ATM in the link layer with frame relay, fiber channel, HiPPI, or others, as necessary.

Switching provides an interconnection mechanism for improving the overall performance characteristics of the network and, when designed properly, can optimize traffic flows. As the design process becomes complicated, however, routing should be considered part of the interconnection strategy.


11.6 Routing

Routing is forwarding network-layer (IP) packets between IP end points across one or more networks. This is based on routers learning about the connectivity within and between networks and applying this connectivity information to forward IP packets toward their destinations. Routing is at a higher layer in the networking hierarchy and thus can have a much larger addressing scope. This is evidenced by the largest IP network, the Internet, which has worldwide scope and interconnects millions of devices.

Routing can be applied to the design as the sole interconnection mechanism or as an addition to a switching mechanism. In either case, it provides support for complex and large network designs (consider the size and complexity of the Internet) and offers features beyond the switching mechanism. From a scalability perspective, the same capacity-planning guidelines can apply to routing. Thus, when the maximum or sustained data rates of traffic flows are high enough to warrant segmenting a shared-medium network, routing could be used as the interconnection mechanism and routers can be placed between the networks.

Routers are also convenient devices to place security and management services, user interfaces, and accounting and administration. Routers support these services well, although their performance can suffer when too many services are placed on them. They are best placed at strategic locations in the network, such as where traffic flows are consolidated or where hierarchy occurs within the design. Since they route at the network layer, routers have access to network-layer information (e.g., source/destination IP addresses, port numbers, protocol information) that happens to be useful to support services. Since routers examine network-layer information, it is logical to use such information for other purposes, such as filtering traffic based on the source IP address or keeping counters of packet information for access by the Simple Network Management Protocol (SNMP).

When routers have support services in place, they make good locations to demark (generate and/or terminate) administrative boundaries. This is enhanced by routing protocols, which understand administrative boundaries through autonomous system (AS) numbers and routing areas. One feature of having such administrative boundaries is the ability to apply routing policies, higher-level abstractions of routing, to the network. As administrative features evolve, the ability to provide accounting information about the network will become increasingly important as a feedback loop in service support.

Another key aspect of routing is the inherent support for redundancy. By its nature, routing is closely tied to redundancy. In fact, without redundancy there really is no need for routing. As the degree of redundancy and/or the number of paths increases, routing increases in importance.

All of the aforementioned features help make routing a logical choice for external connectivity. When connecting to the Internet, IP routing is required. As trust declines in allowing outside connections to internal enterprise or personal resources, the security, monitoring, and administrative abilities associated with routers become essential in operating a network with external access. The combination of routing, external connectivity, and support services has led from placing routers between internal and external networks to the concept of the isolation LAN, also known as a demilitarized zone, as a boundary for external access. This concept, enhanced by the proliferation of Web information access and transfer, has led to a new term for such networks, the intranet. In the intranet in Figure 11.11, not only is there a separation of administrative boundaries, but information itself is also separated into external and internal resources.

Click To expand
Figure 11.11: Evolution of external interfaces.


11.7 Hybrid Mechanisms

As we have seen in this chapter, there are benefits with both switching and routing, and some mechanisms have been developed that combine these mechanisms in various ways. Interconnection mechanisms that combine characteristics of switching and routing are termed here hybrid mechanisms.

In this section, we will discuss the following hybrid mechanisms: LANE, MPOA, nonbroadcast multiple access (NBMA) hybrid mechanisms, service switching, and IP switching. As we will see, these interconnection mechanisms combine characteristics of switching and routing, as well as other characteristics discussed earlier (multicast capability, connection orientation, offered abilities and services, performance upgrades, and flow considerations).

11.7.1 NHRP

The NHRP is one method to take advantage of a shorter, faster data-link layer path in NBMA networks. For example, if we have multiple IP subnetworks using the same NBMA infrastructure, instead of using the standard IP path from source to destination, NHRP can be used to provide a shorter path directly through the NBMA network, as in Figure 11.12.

Click To expand
Figure 11.12: NHRP flow optimization in an NBMA environment.

NHRP provides a path through the NBMA network toward the destination. If the destination is directly on the NBMA network, the path will be to the destination. When the destination is beyond the NBMA network, the path will be to the exit router from the NBMA network closest to the destination.

NBMA is one method for diverging from the standard IP routing model to optimize paths in the network. A strong case for the success of a method such as NHRP is the open nature of the ongoing work on NHRP by the Internet Engineering Task Force, along with its acceptance as part of the MPOA mechanism.

11.7.2 MPOA

MPOA applies NHRP to LANE to integrate LANE and multiprotocol environments and to allow optimized switching paths across networks or subnetworks. MPOA is an attempt to build scalability into ATM systems, through integrating switching and routing functions into a small number of NHRP/MPOA/LANE-capable routers and reducing the routing functions in the large number of edge devices.

MPOA builds on LANE to reduce some of the trade-offs discussed earlier with LANE. First, by integrating LANE with NHRP, paths between networks or subnetworks can be optimized over the ATM infrastructure. We now also have an integrated mechanism for accessing other network-layer protocols. The complexity trade-off with LANE is still there, however, and is increased with the integration of NHRP with MPOA. There are numerous control, configuration, and information flows in an MPOA environment, between MPOA clients (MPCs), MPOA servers (MPSs), and LECSs. In each of these devices reside network-layer routing/forwarding engines, MPOA client-server functions, LANE client functions, and possibly NHRP server functions.

It should be noted that, until link-layer and network-layer functions are truly integrated, perhaps through a common distributed forwarding table (combining what we think of today as switching and routing tables), where and how information flows are configured, established, and maintained by the network will be quite confusing. MPOA may be an answer toward this integration, as well as PNNI or NHRP.

11.7.3 Service Switching

Service switching is switching based on flow or end-to-end information, dependent on the type of service required. Service switching is used to generically describe mechanisms for optimizing paths in a hybrid switching/routing environment, based on determining when to switch or route traffic (Figure 11.13).

Click To expand
Figure 11.13: Using end-to-end or flow information to make forwarding decisions.

Multiple vendors are deploying their own standards for hybrid mechanisms, and since networking vendors and vendor-specific interconnection mechanisms are purposefully avoided in this book, the generic term is used instead.

For example, one criterion for determining when to route or switch is the amount of traffic transferred during an application session or the size and duration of the flow. The concept behind this is to be able to amortize the costs of setting up and tearing down switched connections over large amounts of traffic. It does not make sense to go through the overhead of setting up a connection (e.g., via ATM) through the network to send one or a few packets, frames, or cells of information, which is likely for some traffic types (ping, network file server, domain name system, and UDP in general). On the other hand, for traffic types that typically transfer relatively large amounts of information (FTP and TCP in general), this overhead is a small percentage of the transferred information.

We can use some general rules to determine when to switch or route. Some examples include either counting the number of cells, frames, or packets that have the same destination address and session type or using the port number of the traffic flow. We may choose to route all UDP traffic and switch TCP traffic or switch traffic with particular port numbers. Although this mechanism provides some optimization between switching and routing, it by itself does not address end-to-end services. It appears that this mechanism is particularly useful when switching a large number of connections of different types of information, which is likely to occur over backbones or at traffic aggregation points in the network.

Another mechanism is to take a more generic approach to distinguish traffic types. By allowing devices such as routers to create labels to identify a particular characteristic of traffic (protocol, transport mechanism, port ID, even useror application-specific information), these labels can be exchanged between devices to allow them to handle labeled traffic in special ways, such as providing priority queues, cutthrough paths, or other service-related support for the traffic. This type of mechanism has the advantage of being configurable for a particular environment, especially if it can support user-or application-specific requirements.

Now let's take a look at the interconnection mechanisms presented in this chapter, along with evaluation criteria. Figure 11.14 presents a summary of this information. When an interconnection mechanism is evaluated against a criterion, it may be optimized for that criterion (+), it may have a negative impact on that criterion (-), or it may not be applicable to the criterion (N/A). Each interconnection mechanism is evaluated against design goals and criteria developed in this chapter. You can use this information as a start toward developing your own evaluation criteria. There will likely be customer- and environment-specific criteria that can be added to what is presented here, or you may develop a set of criteria that is entirely different, based on your experience, perspectives, customers, and environments.

 | Shared-Medium | Switching | Routing | LANE | MPOA | 2225 | NHRP | Service Switching
Scalability | - | 0 | + | 0 | + | - | + | 0 to +
Optimizing Flow Models | - | + | 0 | 0 | + | 0 | + | +
External Connectivity | - | - | + | - | 0 | + | 0 | 0
Support For Services | 0 | 0 to + | 0 | 0 | + | - | + | +
Cost | + | + | - | + | + | 0 | + | +
Performance | - | + | + | 0 | 0 | 0 | + | +
Ease of Use | + | + | 0 | - | - | 0 | - | -
Adaptability | - | 0 | + | + | + | 0 | + | +

Figure 11.14: Summary of evaluation criteria for interconnection mechanisms.


11.8 Applying Interconnection Mechanisms to the Design

Interconnections are important from at least two perspectives: They are used to change the degree of concentration of networks or flows at the interconnection (hierarchy), as well as the number of alternate paths provided by the interconnection mechanisms (redundancy). Recall from Chapter 1 that a major trade-off in networking is between hierarchy and interconnectivity. In this chapter, we consider the use of interconnectivity to provide redundancy in the network.

11.8.1 Hierarchy

Throughout the first part of this book, we looked for locations where information comes together in the network, whether it is applications, users, flows, or broadcast domains, and we examined where boundaries between areas occur. Such locations point to a consolidation of information, which leads to the formation of hierarchies in the network. Hierarchies play an important role in interconnection mechanisms, for as they indicate consolidation points in the network, they are likely to show where multiple technologies interconnect.

Some metrics for measuring hierarchy in the network are the concentration of flows, technology connections at or within an area, and the number of networks or areas that are interconnected. We can describe the degree of hierarchy as low, medium, or high, based on the following criteria (Figure 11.15):

Degree of Hierarchy | Concentration of Routing Flows/Levels
None | 1:1
Low | 2:1
Medium | 3-5:1
High | >5:1

Figure 11.15: Degrees of hierarchy.

11.8.2 Redundancy

Redundancy, or the number of alternate paths in the network, is an important part of providing reliability in the network. Another commonly used term associated with redundancy is path diversity. Looking at the number of alternate paths is a fairly simple view of redundancy and is not end-to-end. To evaluate end-to-end redundancy, we must consider all components in the end-to-end path, which is often a complex task. A simple view of redundancy is often sufficient in determining criteria for interconnection.

During the requirements and flow analyses, we discussed and listed service metrics for reliability, but until this section, we have not been able to do much in the network design to support it. Where mission-critical applications and predictable/guaranteed reliability occurs in flows, redundancy is likely to be required. There are two components of redundancy to consider: the number of paths at convergence points and the degree of redundancy provided by alternate paths. In providing alternate paths in the network, there will be locations where these paths converge. It is at these convergence points where redundancy effects the interconnection mechanism.

Alternate paths can provide various degrees of redundancy in a network. Consider the following examples.

Low-Redundancy Path

In a low-redundancy path, the alternate path may not be immediately available when the primary path is disabled. There may be some configuration, possibly even human intervention, required to make the alternate path operational. This means that there will be a significant delay, on the order of minutes, while the alternate path is brought up. Furthermore, the performance characteristics of this alternate path may be significantly less than those of the primary path.

Low-redundancy paths are often known as cold spares. This is the same situation as when a failed component requires replacement from on-site spares before service can be restored.

Figure 11.16 shows a path with a low degree of redundancy. This means that the user or application will encounter a disruption in service and degradation in perceived performance, in terms of either greater delay or loss of the application session.

Click To expand
Figure 11.16: Low-redundancy path.

Medium-Redundancy Path

In a medium-redundancy path, the alternate path is readily available (i.e., no significant setup time to bring the alternate path up). However, the alternate path has a lower degree of performance than the primary path. Readily available means that the alternate path may be immediately available or there may be a short wait (milliseconds to seconds) while flows are rerouted across the alternate path, but no human intervention is required.

If the time to switch to the redundant path is faster than the time required to notice the failure, it can be considered auto-switch-over redundancy. When the failure is noticed before the path can be switched, it can also be termed a hot-standby path.

In Figure 11.17, the redundant path (the T1) is ready to work and can be cut over quickly by a routing protocol. It has lower capacity, however, and would likely result in degraded performance for its users. This is a medium degree of redundancy, where users and applications will (usually) not notice a disruption in service, although there will be a degradation in perceived performance when the alternate path is established.

Click To expand
Figure 11.17: Medium-redundancy path.

High-Redundancy Path

The highest degree of redundancy is when one or more alternate paths are readily available and the performance of each alternate path is the same as that of the primary path. In Figure 11.18, the redundant path is equal in performance, both capacity and delay, to the primary path.

Click To expand
Figure 11.18: High-redundancy path.

A high-redundancy path means that important users and applications (e.g., mission-critical or real-time applications) will not notice a disruption in service and will enjoy the same level of performance with the alternate path. Ideally, this degree of redundancy means that users never notice when the primary path fails. We have to be careful when applying this degree of redundancy, for there is a tendency to ignore failovers when service to users and applications does not change. Thus, network management needs to be able to identify when such failovers occur and must notify management.

When equal performance paths are used and the traffic load is shared between them during normal (nonfailover) operation, this would not be considered high redundancy. When the normal traffic load is shared across the equal paths, the loss of the primary path would result in a perception of degraded performance by users.

An obvious trade-off between the different degrees of redundancy is in cost. Providing a low degree of redundancy is relatively cheap, and a high degree of redundancy is almost, if not entirely, equal to building a second backup network.

We can summarize the degrees of hierarchy and redundancy as low, medium, or high, based on the guidelines developed in this book and shown in Figure 11.19.

Click To expand
Figure 11.19: Guidelines for hierarchy and redundancy.

These guidelines for hierarchy and redundancy in the network are useful not only in developing interconnection mechanisms but also in developing network management, security, and addressing and routing strategies for our design.


11.9 Where to Go from Here

In this book, we have discussed the processes for analyzing, architecting, and designing networks. Although this book provides a comprehensive view of developing network architectures and designs, there are still many areas of work left to do after the network design is completed, including:

  • Evaluating vendors of network devices and services (This includes developing the request for information [RFI], request for purchase [RFP], and request for quote [RFQ].)

  • Procuring network devices and services

  • Planning the deployment (including staging) of the network project

  • Testing the network at various stages of deployment, to ensure that project goals are being met

  • Documenting the results of the project

It is my sincere hope that you have found this book useful. Good luck with your network projects!


11.10 Conclusion

In this chapter, we completed the network design process by examining interconnection strategies. Whether it is shared media, routing, or one of the variants of switching, understanding how these strategies work is fundamental to applying them in the network design.

Having completed the analysis, architecture, and design processes, you are ready to begin planning and installing the network. All of the material developed through these processes will help you during these phases of the project.


11.11 Exercises

  1. Using the guidelines presented in Section 11.4, recommend whether or not hierarchy should be introduced in the following shared-media networks:

    1. A 10 Mb/s Ethernet network that bursts to a 9 Mb/s peak data rate

    2. A 100 Mb/s FDDI network that supports a sustained data rate of 40 to 45 Mb/s

    3. A 10 Mb/s Ethernet network that supports composite traffic flow F1, which consists of

      1. A client-server flow with a capacity of 400 Kb/s

      2. A distributed-computing flow with a capacity of 1.2 Mb/s

      3. A real-time video flow with a capacity of 2.7 Mb/s

  2. Consider a network design in which there is an existing base of PCs and workstations with Ethernet interfaces. Current capacity requirements are beyond 10 Mb/s, and the customer wants to keep his or her investment in Ethernet NICs. The company is migrating from a shared network and is looking at IP routers, Ethernet 10 and 100 Mb/s switches, and LANE as possible options. Compare and contrast these options, disregarding capacity for the moment. Answer the following questions:

    1. What distinguishing characteristics of the network design indicate each of these options?

    2. What requirements of the network design would be needed to be better able to make a choice?

  3. A customer wants to use LANE as a step to migrate the user devices with Ethernet interfaces to an RFC 2225 network. The devices will start with Ethernet NICs and migrate to having ATM OC-3c NICs in the RFC 2225 network, as shown in Figure 11.20.

    Click To expand
    Figure 11.20: LANE and RFC 2225 networks for Exercise 3.

    Outline the design of the LANE network, showing all LANE servers (LECS, LES, BUS, SMS) and the connectivity between them and with the clients. Include how clients will be migrated from the LANE network to the RFC 2225 network as their NICs are upgraded from Ethernet to ATM OC-3c. What changes need to be made to device configurations as they are migrated to the RFC 2225 network?

  4. For each of the following situations, would you recommend routing or switching? Explain your choices.

    1. A workgroup of 100 workstations within a building using client-server applications and sharing a common IP subnet address.

    2. Connecting your customer's LAN to the Internet via a dedicated T1 from an ISP.

    3. A backbone between several organizations within a corporation. Each organization wants to be secure from the other organizations and requires that traffic is monitored between organizational boundaries.

  5. For many hybrid mechanisms, traffic flows can have routed paths or switched paths, depending on the characteristics of each flow. Given the descriptions of switching and routing presented in this book, when would you recommend that a flow be switched, and when would it be routed? Present recommendations based on the following:

    1. Duration of each flow in terms of the numbers of cell, frames, and/or packets

    2. Type of each flow, by protocol or application

    3. Performance requirements of each flow

    4. Destination and/or source of each flow, as link-layer or network-layer addresses


Glossary of Terms

Numbers

80/20 rule
A rule of thumb by which 80% of a network's traffic is local and 20% is remote.


A-B

Adaptability
A user requirement for the system to be able to adapt to users' changing needs.
Address
For IP, a 32-bit number that identifies a device at the network layer.
Addressing
Applying identifiers (addresses) to devices at various protocol layers (e.g., data-link and network).
Address mask
For IP, a 32-bit number that identifies which bits in the address are considered part of the network and (by default) which bits are considered part of the device.
Address prefix
When an address mask is noted by its length (N) in bits, as /N.
Addressing
Assigning local or global, private or public, temporary or persistent identifiers to devices.
Affordability
A user requirement for what users or management can afford to purchase for the network.
Alarm
A network management event that triggers a real-time notification to network personnel.

See also Event.

Application requirements
Requirements that are determined from application information, experience, or testing and are what are needed by applications to successfully operate on the system.
Architectural components
These are functional areas of the network, whose relationships define the network architecture. Examples of architectural components include IP services, security and privacy, network management, and addressing and routing.
Areas
Segments of a network design that are the result of sizing the network.
Asynchronous applications
Applications that are relatively insensitive to time, either assuming no timing relationship between source and destination or that the timing relationship is outside the bounds of the applications session.
Audit trail
The set of documents, data, and decisions for the architecture and design.
Autonomous system (AS)
A collection of networks that are under the same management control.
Availability
The relationship between the frequency of mission-critical failures and the time to restore service. This is also known as operational availability.
Bandwidth
The theoretical capacity of one or more network elements in the system.
Bandwidth*delay product
An estimate of the maximum amount of information that may be in transit across a particular technology at any given time.
Best-effort service
Network service in which there is no control over how the network will satisfy the service request and there are no guarantees associated with this service. Service will be both unpredictable and unreliable, with variable performance across a range of values (from the network being unavailable [0 performance] to the lowest common denominator of performance across all of the technologies in the end-to-end path).
BGPv4
A path-vector-based External Gateway Protocol.
Blocking
When computing devices halt their computations, waiting for information from other computing devices.
Broadcast domain
A group of network-addressable devices where all of the devices in that group can be reached by a single network address, the broadcast address.
Broadcast technologies
Network technologies that support the ability of a device to communicate simultaneously with all other devices on their network or subnet, through using a well-known broadcast address specific to the network technology.


C

Call admission control
A mechanism to limit the number of calls on a network and thus control the allocation of resources.
Capacity
A measure of the system's ability to transfer information (voice, data, video, combinations of these).
Capacity plan
A written description of network performance (capacity) required for the flows that are described in the flowspec.
Capacity planning
Overengineering bandwidth in the network to accommodate most short- and long-term traffic fluctuations. Also known as traffic engineering.
Centralized management
When all management data (e.g., pings, SNMP polls/ responses, traceroutes) radiate from a single (typically large) management system.
Characterizing behavior
Representing how users and applications use the network to develop and understand their requirements.
Checks and balances
Methods to duplicate measurements to verify and validate network management data.
CIDR block
A group of network addresses that are represented by a classless interdomain routing (CIDR) advertisement of the form (network address, mask length).
Classful addressing
Applying predetermined mask lengths to addresses to support a range of network sizes. The result is a set of classes of addresses (A, B, C, D, and E), each of which supports a different maximum network size.
Classification
The ability to identify traffic flows as part of traffic conditioning.
Classless interdomain routing
The absence of class boundaries in network routing.
Client-server architectural model
An architectural model that follows the client-server flow model. In this case there are obvious locations for architectural features, in particular where flows combine.
Client-server flow model
A flow model in which the flows are asymmetric and hierarchically focused toward the client.
Closely coupled
In the distributed-computing flow model, when there are frequent transfers of information between computing devices.
Coarse granularity
In the distributed-computing flow model, when each task is dedicated to a single computing device.
Component characteristics
The characteristics between architectural components (IP services, network management, security and privacy, and addressing and routing) that describe the relationships between these components. These characteristics are operation, interactions, dependencies, trade-offs, and constraints.
Component constraints
Restrictions within a component architecture or between component architectures; can even be across the entire (reference) architecture.
Component dependencies
Requirements that one component has on one or more other components in order to function.
Component interactions
The requirements that each component has to communicate with other components.
Component operation
Determining the mechanisms that make up each component, how each mechanism works, and how that component works as a whole.
Component trade-offs
Decision points in the development of an architecture to prioritize and choose between features and functions of each component and thereby optimize the overall (reference) architecture.
Composite flow
A combination of requirements from multiple applications, or of individual flows, that share a common link, path, or network.
Confidence
A measure of the ability of the network to deliver data without error or loss at the design throughput.
Configuration
For network management, the setting of parameters in a network element for operation and control of that element.
Conforming traffic
Traffic that is within performance boundaries as determined by metering (traffic conditioning).
Connection support
When a connection is established by the technology whenever information is transferred across the network.
Content delivery network
A network that bypassed the core of the Internet to provide better performance in delivering information to its users.
Critical flows
Flows that are considered more important than others in that they are higher in performance, have strict requirements, or serve more important users, applications, and devices.


D-E

Data flows

See Flows.

Data sink
A device that collects or terminates data on a network.
Data source
A device that produces data on a network.
De facto standard
A standard that is generally accepted through being widely implemented and used.
Default route
The route used when there is no other route for that destination. It is the route of last resort.
Default route propagation
The technique used to inform the network (or subnets or functional areas) of the default route.
Delay
A measure of the time difference in the transmission of information across the system.
Differentiated services
A quality-of-service mechanism that defines a set of values (termed differentiated services code points [DSCPs]) for classes of traffic flows to be used by resource control mechanisms.
Directionality
The preference of a flow to have more requirements in one direction than in another.
Distributed-computing architectural model
An architectural model that follows the distributed-computing flow model and in which the data sources and sinks are obvious locations for architectural features.
Distributed-computing flow model
A flow model that either has the inverse of the characteristics of the client-server flow model or is a hybrid of peer-to-peer and client-server flow models.
Distributed management
When there are multiple separate components to the management system and these components are strategically placed across the network, localizing network management traffic and distributing management domains.
Downstream
Traffic flowing in the direction from the source to the destination.
Dropping
In traffic conditioning, discarding nonconforming traffic.
Encryption
A security mechanism in which cipher algorithms are applied together with a secret key to encrypt data so that they are unreadable if intercepted.
End-to-end architectural model
Architectural model that focuses on all components in the end-to-end path of a traffic flow.
End-to-end (network element) characteristics
Characteristics that can be measured across multiple network elements in the path of one or more traffic flows and may extend across the entire network or between devices.
Environment-specific thresholds
Performance thresholds that are determined for the environment of the current network project on which you are working.
Event
Something that occurs in the network that is worthy of noting, whether informational, as a problem, or as an alarm.
Exterior Gateway Protocols
Routing protocols that communicate routing information (reachability and metrics) primarily between ASs.
External interfaces
The network interfaces between your network and other, outside (external) networks.


F-G

Features
Network functions and performance that are desired but are not necessary for the network to successfully support its users, applications, and devices.
Fine granularity
In the distributed-computing flow model, in which a task is sub-divided between several devices and the computing is done concurrently.
Firewalls
Combinations of one or more security mechanisms, implemented in devices or network elements (routers), which are placed at strategic locations within a network.
Flow analysis
The process of characterizing traffic flows for a network, where they are likely to occur, and what levels of performance they will require.
Flows
Sets of network traffic (application, protocol, and control information) that have some common attributes, such as source/destination address, information type, routing, or other end-to-end information. Flows also have directionality. Also known as traffic flows or data flows.
Flow-based architectural models
Models that take particular advantage of traffic flows from the flow specification.
Flow models
Groups of flows the exhibit specific, consistent behavior characteristics. Flow models are characterized primarily by their directionality, hierarchy, and interconnectivity.
Flow prioritization
Ranking flows based on their importance (e.g., number or users, applications, or devices supported).
Flow specification
A listing of the flows for a network, along with their performance requirements and priority levels (if any). Also known as a flowspec.
Flowspec

See Flow specification.

Flowspec algorithm
A mechanism to combine the performance requirements (capacity, delay, and reliability) for flows in such a way that describes the optimal composite performance for that flow or group of flows.
Function
A major capability of a network.
Functional architectural models
Models that focus on one or more functions or features planned for in the network.
Functional areas
Groups within the system that share a similar function. Groups may be of users (workgroups), applications, devices, or combinations of these, and they may share similar jobs/tasks, physical locations, or functions within the network (e.g., backbone routing).
General access
Common access of users to applications, computing, and storage resources across a network.
General-performance network
A network that does not have a distinctive set of applications, users, or hosts that would be the performance driver for that network.
General thresholds
Performance thresholds that apply to most or all networks.
Generic computing devices
Common desktop and laptop computers that most users have.
Guaranteed service
Network service that is predictable and reliable to such a degree that, when service is not available, the system is in some way held accountable.


H-I

Hard boundary
A routing boundary in which Exterior Gateway Protocols are predominantly used to pass routing information.
Hard state
Determining and persistently maintaining connection information along the path of a connection, between source and destination.
Hierarchical client-server architectural model
An architectural model based on the hierarchical client-server flow model. In addition to the functions, features, and services being focused at server locations and client-server flows, they are also focused at the server-server flows.
Hierarchical client-server flow model
A flow model that has the characteristics of a client-server flow model but that also has multiple layers, or tiers between servers.
Hierarchical management
When the management functions (monitoring, display, storage, and processing) are separated and placed on separate devices.
Hierarchy
The degree of concentration of networks or traffic flows at interconnection points within the network, as well as the number of tiers of interconnection points within the network.
High performance
An indicator that the service request or requirement's performance characteristics are greater than a performance threshold determined for that network.
High-performance network
A network that typically has one or a few applications, users/groups, and/or devices whose performance requirements are significantly greater than other performance requirements for that network.
High-performance/general-performance architectural model
Model that focuses on identifying networks or parts of a network as general performance, as high performance, or as having components of both.
Human response time
An estimate of the time threshold when users begin to perceive delay in the system.
In-band management
When the data flows for network management follow the same network paths as the traffic flows for users and their applications.
Individual flow
The flow associated with a single session of an application.
Initial conditions
Initial input to the requirements analysis process, consisting of the type of network project, scope of the architecture and design, initial architecture/design goals, and any outside forces acting on the network.
Instrumentation
For network management, the set of tools and utilities needed to monitor and probe the network for management data.
Interconnection mechanisms
Mechanisms that interconnect network technologies, including shared media, switching, bridging, and routing.
Integrated services
A quality-of-service mechanism that defines values and mechanisms for allocating resources to flows across the end-to-end path of the flow.
Interactive applications
Applications that assume some timing relationship between source and destination while the application session is active, however, the timing relationship is not as strict as it is in real-time.
Interactive bulk applications
Applications in which the end-to-end or round-trip network delays are not the predominant delay for that application, but processing at the device or application component is the predominant delay.
Interactive burst applications
Applications in which the end-to-end or round-trip network delays are the predominant delay for that application.
Interactivity
A user requirement for a response time from the system (as well as the network) that is on the order of the response times of users.
Interconnectivity
A balance to hierarchy in a network, interconnectivity is the degree of connections within the network at different levels in the design, to provide greater performance through parts of the network.
Interior Gateway Protocols (IGPs)
Routing protocols that communicate routing information primarily within an AS.
Intranet/extranet architectural model
Architectural model that focuses on security and privacy, including the separation of users, devices, and applications based on secure access.
IPSec
A protocol for providing authentication and encryption between devices at the network layer.
IP services
A set of mechanisms to configure, operate, manage, provision, and account for resources in the network that allocate performance to users, applications, and devices.


L-N

Latency
System or component response time, a measure of delay that incorporates device and application processing, taking into account the time to complete a task.
Limit
A boundary between conforming and nonconforming regions; is taken as an upper or lower limit for a performance characteristic.
Loosely coupled
In the distributed-computing flow model, when there may be little to no transfer of information between computing devices.
Low performance
An indicator that the service request or requirement's performance characteristics are less than a performance threshold determined for that network.
Maintainability
A statistical measure of the time to restore the system to fully operational status after it has experienced a fault.
Marking
Tagging an IP packet with a priority level, as part of traffic conditioning.
Mechanisms
Hardware and software that help a network to achieve each function.
Metadata
Additional information about the collected data, such as references to the data types, time stamps of when the data were generated, and any indications that these data reference any other data.
Metering
Measuring the temporal performance characteristics of a traffic flow, as part of traffic conditioning.
MIB selection
Determining which SNMP MIBs to use and apply, as well as which variables in each MIB are appropriate, for your network.
Mission-critical applications
Applications that require predictable or high reliability.
Monitoring
Obtaining values for end-to-end, per-link, and per-element network management characteristics.
Multipart flowspec
A flow specification that describes flows that have guaranteed requirements; may include flows that have stochastic and/or best-effort requirements.
Natural mask
The IP address mask that coincides with a class boundary.
Network address translation
The mapping of IP addresses from one realm to another. Typically this is between public and private address space.
Network analysis
Studying network components, its inputs and outputs, to understand network behavior under variable situations.
Network architecture
Developing a high-level end-to-end structure for the network. This includes the relationships between major architectural components of the network, such as security, network management, addressing, and routing.
Network design
Details (physically) the reference network architecture, evaluating and choosing technologies for each area of the network, as well as developing strategies to connect these technologies across the network.
Network element
An individual component of the network that participates at one or more of the protocol layers.
Network environment
Everything that is external to the network, such as the physical or business environments. Can also include users, applications, and devices, although they are usually considered with the network to be part of the system.
Network management
Providing functions to control, plan, allocate, deploy, co-ordinate, and monitor network resources.
Network perimeter security
Protecting the external interfaces between your network and external networks.
Network propagation delay
An estimate of how long it takes for a signal to cross a physical medium or link.
Network privacy
A subset of network security, focusing on protection of networks and their services from unauthorized access or disclosure.
Network requirements
Requests for capabilities in the network, usually in terms of performance and function, that are necessary for the success of that network.
Network security
The protection of networks and their services from unauthorized access, modification, destruction, or disclosure. It provides assurance that the network performs its critical functions correctly and that there are no harmful side effects.
Network services
Levels of performance and function in the network.
Nonbroadcast multiple access technologies
Network technologies that do not inherently have broadcast support.

See also Broadcast technologies.

Nonconforming traffic
Traffic that is outside of performance boundaries, as determined by metering (traffic conditioning).
Non-real-time applications
Applications with various end-to-end delay requirements, at times more stringent (in terms of the amount of delay) than real-time applications, but the destination will wait (within reason) until the information is received.
Northbound interface
A management interface that is oriented toward higher-level (thus up or northbound) management functions. This term is commonly used for the interface from network management to service or business management.


O-P

One-part flowspec
A flow specification that describes flows that have only best-effort requirements. Also known as a unitary flowspec.
Operational suitability
A measure of how well our network design can be configured, monitored, and adjusted by the customer's operators.
OSPF
An IGP that is based on a link-state algorithm.
Out-of-band management
When different paths are provided for network management data flows and user traffic flows.
Packet filtering
A mechanism in network elements to explicitly deny or pass packets at strategic points within the network.
Peers
Users, applications, devices, networks, or ASs that act at the same level in their hierarchy. For example, in a hierarchical client-server model, servers that act at the same level (e.g., directly above their clients) are considered peers. ASs that form a peering arrangement (using BGP4 and policies) are considered peers.
Peer-to-peer architectural model
Based on the peer-to-peer flow model, the important characteristics of this model are that there are no obvious locations for architectural features; functions, features, and services toward the edge of the network, close to users and their devices; and flows are end-to-end between users and their devices.
Peer-to-peer flow model
A flow model in which the users and applications are fairly consistent throughout the network in their flow behaviors.
Performance
The set of levels for capacity, delay, and reliability in a network.
Per-link and per-element (network element) characteristics
Characteristics that are specific to the type of element or connection between elements being monitored.
Physical security
The protection of devices from physical access, damage, and theft.
Planned hierarchy
Integrating into the network design methods to isolate and hide networks and their traffic from one another.
Policies
(1) Sets (formal or informal) of high-level statements about how network resources are to be allocated among users. (2) High-level statements about relationships between networks or ASs, as with peering arrangements. A policy may take an action (e.g., drop, accept, modify) on traffic that matches one or more AS parameters (e.g., AS number or list of AS numbers and metrics).
Polling
Actively probing the network and network elements for management data.
Polling interval
Time period between polls.

See also Polling.

Primary storage
Storage locations where data are staged for short periods (e.g., hours).
Privacy
A requirement to protect the sanctity of user, application, device, and network information.
Private IP addresses
IP addresses that cannot be advertised and forwarded by network elements and devices in the public domain (i.e., the Internet).
Public IP addresses
IP addresses that can be advertised and forwarded by network elements and devices in the public domain (i.e., the Internet).
Public key infrastructure
A security infrastructure that combines security mechanisms, policies, and directives into a system that is targeted for use across unsecured public networks (e.g., the Internet), where information is encrypted through the use of a public and a private cryptographic key pair that is obtained and shared through a trusted authority.


Q-R

Quality
In requirements analysis, refers to the user requirement for quality of the presentation to the user.
Quality of service
Also known as QoS; determining, setting, and acting on priority levels for traffic flows.
Rate-critical applications
Applications that require a predictable, bounded, or high degree of capacity.
Real-time analysis
Setting and monitoring of thresholds or boundaries for end-to-end, per-link, or per-element characteristics for short-term or immediate notification of events and transients.
Real-time applications
Applications that have a strict timing relationship between source and destination, with one or more timers set for the receipt of information at the destination.
Reference network architecture
A description of the complete architecture, considering all of its components. It is a compilation of the relationships developed during the network architecture process.
Reliability
(1) A statistical indicator of the frequency of failure of the network and its components and represents the unscheduled outages of service. (2) In requirements analysis, reliability is a user requirement for consistently available service.
Remote access
Network access based on traditional dial-in, point-to-point sessions, and virtual private network connections.
Requirements
Descriptions of network functions and performance that are needed for the network to successfully support its users, applications, and devices.
Requirements analysis
Gathering and deriving requirements in order to understand system and network behaviors.
Requirements map
A diagram that shows the location dependencies between applications and devices, which will be used for flow analysis.
Requirements specification
A document that lists and prioritizes the requirements gathered for your architecture and design.
Resource control
Mechanisms that will allocate, control, and manage network resources for traffic.
RIP and RIPv2
IGPs that are based on a distance-vector routing algorithm.
Route aggregation
The technique exchanging of routing information between ASs, usually between service providers with transit networks, and between large customer networks.
Route filter
A statement, configured in one or more routers, that identifies one or more IP parameters (e.g., an IP source or destination address) and an action (e.g., drop or forward) to be taken when traffic matches these parameters.
Route filtering
The technique of applying filters to hide networks from the rest of an AS or to add, delete, or modify routes in the routing table.
Routing
Learning about the connectivity within and between networks and applying this connectivity information to forward IP packets toward their destinations.
Routing boundaries
Physical or logical separations of a network based on requirements for or administration of that network.
Routing flows
Flows of routing information, passed between functional areas and between ASs.


S

Scheduling
Determining the order in which traffic is processed for transmission onto a network.
Secondary storage
Storage sites that aggregate management data from multiple primary storage sites.
Secure sockets library
A security mechanism that uses RSA-based authentication to recognize a party's digital identity and RC4 to encrypt and decrypt the accompanying transaction or communication.
Security
A requirement to guarantee the integrity (accuracy and authenticity) of a user's information and physical resources, as well as access to the user's and system's resources.
Security awareness
Getting users educated and involved with the day-to-day aspects of security in their network and helping them understand the potential risks of violating security policies and procedures.
Security cell
In the network architecture, when security constrains performance to operate within a security perimeter, or cell.
Security policies and procedures
Formal statements on rules for system, network, and information access and use designed to minimize exposure to security threats.
Server
Computing device that provides a service to one or more users (i.e., clients).
Service

See Network services.

Service characteristics
Individual network performance and functional parameters that are used to describe services.
Service levels
A group or set of characteristics that forms a higher-level representation of services.
Service metrics
Measurements of service characteristics in the network to monitor, verify, and manage services.
Service-level agreement
Also known as an SLA, an informal or formal contract between a provider and user that defines the terms of the provider's responsibility to the user and the type and extent of accountability if those responsibilities are not met.
Service offering
Services offered by the network to the rest of the system.
Service plan
A written description of the network performance (capacity, delay, and reliability) required for the flows that are described in the flowspec.
Service request
Network services that are requested by users, applications, or devices.
Service-provider architectural model
Architectural model based on service-provider functions, focusing on privacy and security, service delivery to customers (users), and billing.
Service switching
Switching based on flow or end-to-end information, dependent on the type of service required.
Session
An instance of one or more concurrent applications, resulting in one or more traffic flows.
Shaping
In traffic conditioning, delaying traffic to change a performance characteristic.
Shared-medium mechanism
When all devices on the network (or subnetwork) share the same physical medium.
Soft boundary
A routing boundary in which IGPs are predominantly used to pass routing information.
Soft state
Determining and maintaining state until the connection is established or for a short period after the connection is established.
Specialized devices
Devices that provide specific functions to their users.
Specific
As used with security, refers to well-defined rules about who, what, and where security is applied.
State
Information (typically local or end-to-end addresses) associated with connections in a technology.
Stateful
Determining and maintaining state information for connections between source and destination.
Stateless
Not determining or maintaining any state information between source and destination for connections.
Static routes
Routes that are configured manually, by network personnel or scripts, in network elements and that do not change until manually deleted or modified.
Stochastic service
Service that requires some degree of predictability (probability), more than best effort, yet does not require the accountability of a guaranteed service.
Storage archives
Secondary and tertiary storage sites for network management data.
Stub network
A network with only one path into or out of it.
Subnet
A segment of a network, created as an additional level of hierarchy imposed on a network, through changing its address mask.
Subnet mask
An address mask that has been changed from its natural (classful) mask to add an additional level of hierarchy.
Subnetting
Using part of the device (host) address space to create another layer of hierarchy. This is done by changing the address mask.
Supernet mask
The address mask created when supernetting—that is, reducing the mask size to aggregate network addresses.
Supernetting
Aggregating network addresses by changing the address mask to decrease the number of bits allocated to the network.
Supportability
A measure of how well the customer can keep the system performing, as designed, over the entire life of the system.
Switching
Forwarding information (e.g., cells, frames, packets) between segments of a network or subnetwork. This is usually done at the link or network layers but may occur at any layer.
System
A set of components that work together to support or provide connectivity, communications, and services to users of the system.
Systems architecture
Developing a high-level end-to-end structure for the system, which consists of users, applications, devices, and networks. This includes the relationships between each of these components.
Systems methodology
Viewing the network that you are architecting and designing, along with a subset of its environment (everything that the network interacts with or impacts), as a system.


T-V

Tele*services
The set of multimedia applications, such as teleseminars, telelearning, teleconferencing, and so on.
Tertiary storage
Storage sites where management data are secure and persistent (permanent or semi-permanent).
Threat analysis
A process used to determine which components of the system need to be protected and the types of security risks from which they should be protected.
Threshold
A value for a performance characteristic that is a boundary between two regions of conformance and, when crossed in one or both directions, will generate an action.
Throughput
The realizable capacity of the system or its network elements.
Topological architectural models
Models based on a geographical or topological arrangement; often used as starting points in the development of the network architecture.
Traffic engineering
Overengineering bandwidth in the network to accommodate most short-and long-term traffic fluctuations. Also known as capacity planning.
Traffic flows

See Flows.

Transients
Short-lived events or changes in the behavior of the network.
Trap
A user-configurable threshold for a parameter. Used in network management.
Trend analysis
Using network management data to determine long-term network behaviors, or trends.
Timeliness
A user requirement to be able to access, transfer, or modify information within a tolerable time frame.
Tunneling
Encapsulating information within protocol headers for the purpose of isolating and protecting that information.
Two-part flowspec
A flow specification that describes flows that have stochastic requirements and may include flows that have best-effort requirements.
Unitary flowspec
A flow specification that describes flows that have only best-effort requirements. Also known as a one-part flowspec.
Upstream
Traffic flowing in the direction from the destination to the source.
User requirements
The set of requirements gathered or derived from user input; what is needed by users to successfully accomplish their tasks on the system.
Variable-length subnetting
Subnetting in which multiple subnet masks are used, creating subnets of different sizes.
Virtual private networks
Applying tunneling to create multiple isolated networks across a common infrastructure.


W-X

Workgroups
Groups of users who have common locations, applications, and requirements or who belong to the same organization.
xDSL
A variety of DSL options, such as asymmetric DSL, symmetric DSL, high-speed DSL, and ISDN DSL.


Glossary of Acronyms

AAAA | authentication, authorization, accounting, and allocation
ABR | available bit rate
ACL | access control list
AF | assured forwarding
AH | authentication header
API | application programming interface
AR | acceptance review
ARCP | asynchronous remote copy
ARP | Address Resolution Protocol
AS | autonomous system
ATM | asynchronous transfer mode
AToM | ATM monitoring
BE | best effort
BER | bit error rate
BGPv4 | Border Gateway Protocol version 4
BSD | Berkeley Software Distribution
BUS | broadcast/multicast server
CA | certificate authority
CAC | call admission control
CAD | computer-aided design/computer-aided drawing
CBC | cipher block chaining
CBQ | class-based queuing
CBR | constant bit rate
CD | compact disk
CDN | content-delivery network
CDR | critical design review
CF | composite flow
CHAP | Challenge-Response Authentication Protocol
CIDR | classless interdomain routing
CIR | committed information rate
CLI | command line interface
CLR | cell loss ratio
CMIP | Common Management Information Protocol
CMOT | CMIP over TCP/IP
CMR | cell misinsertion ratio
COPS | common open policy services
CORBA | common object request broker architecture
CoS | class of service
COTS | commercial off the shelf
CPU | central processing unit
CRM | customer relationship management
CT | computed tomography
DES | data-encryption standard
DET | deterministic
DHCP | Dynamic Host Configuration Protocol
DiffServ | differentiated services
DMZ | demilitarized zone
DNS | domain name system
DR | default route
DSCP | differentiated services code point
DSL | digital subscriber loop
DSx | digital signal (x 1, 3)
DSU | data service unit
dWDM | dense wavelength division multiplexing
EBGP | external BGP
ECS | engineering compute server
EF | expedited forwarding
EGP | External Gateway Protocol
EMS | element management system
ENET | Ethernet
EOC | extended operational capability
ERP | enterprise resource planning
ESP | encapsulating security payload
f | flow
FA | functional area
FAA | Federal Aviation Administration
FB | flow boundary
FCAPS | fault, configuration, accounting, performance, and security
FCIP | fiber channel over IP
FDDI | fiber distributed data interface
FE | Fast Ethernet
FIFO | first in first out
FMECA | failure modes, effects, and criticality analysis
FTE | full-time equivalent/full-time employee
FTP | File Transfer Protocol
FY | fiscal year
Gb/s | gigabits per second
GigE | Gigabit Ethernet
HDLC | high-level data link control
HiPPI | high-performance parallel interface
HMAC | hash-function message authentication code
HRT | human response time
HTTP | HyperText Transfer Protocol
HVAC | heating, vacuum, air conditioning
HW or H/W | hardware
IBGP | internal BGP
ICD | interface control description
ICMP | Internet Control Message Protocol
ID | identifier
IETF | Internet Engineering Task Force
iFCP | Internet Fiber Channel Protocol
IGP | Interior Gateway Protocol
iLAN | isolation LAN
INTD | interaction delay
IntServ | integrated services
I/O | input/output
IOC | initial operational capability
IP | Internet Protocol
IPSec | IP security
ISP | Internet service provider
IT | information technology
IXC | interexchange carrier
Kb/s | kilobits per second
KB/s | kilobytes per second
L | link
L2F | layer 2 forwarding
L2TP | layer 2 Tunneling Protocol
LAN | local area network
LANE | LAN emulation
LDAP | Lightweight Directory Access Protocol
LEC | LAN emulation client
LECS | LAN emulation connection server
LES | LAN emulation server
LIS | logical IP subnet
LLNL | Lawrence Livermore National Lab
LOH | line overhead
LRU | local repair unit
MAN | metropolitan-area network
Mb/s | megabits per second
MB/s | megabytes per second
MC | mission-critical
MD | message digest
MDR | minimum data rate
MFTP | multiple FTP
MIB | management information base
MIS | management information systems
MPC | MPOA client
MPS | MPOA server
MPLS | multiprotocol label switching
MPOA | multiprotocol over ATM
MRI | magnetic resonance imaging
ms | milliseconds
MTBF | mean-time-between-failures
MTBCF | mean time between mission-critical failures
MTBSO | mean time between service outage
MTTR | mean time to repair
NA or N/A | not available
NAP | network access point
NAPT | network address port translation
NAS | network access server
NAT | network address translation
NBMA | nonbroadcast multiple access
NFS | network file server
NHRP | Next-Hop Resolution Protocol
NIC | network interface card
NM | network management
NMS | network management system
NOC | network operations center
NOS | network operating system
NR | network requirement
OAM | operations, administration, and maintenance
OAM&P | OAM and provisioning
OCx | optical carrier (x 1, 3, 12, 24, 48, 192)
OLTP | online transaction processing
ORR | operational readiness review
OS | operating system
OSPF | Open Shortest Path First routing protocol
OSI | open systems interconnect
OSS | operations support system
P | peering
PADI | PPPoE active discovery initiation
PADO | PPPoE active discovery offer
PADR | PPPoE active discovery request
PADS | PPPoE active discovery session
PAP | Password Authentication Protocol
PC | personal computer
PDA | personal digital assistant
PDP | policy decision point
PDR | peak data rate; preliminary design review
PEP | policy enforcement point
PING | packet internet groper
PKI | public key infrastructure
PM | program management
POH | path overhead
PoP | point of presence
PoS | packet over SONET; point of sale
POTS | plain-old telephone service
PP | patch panel
PPP | Point-to-Point Protocol
PPPoE | PPP over Ethernet
PPTP | Point-to-Point Tunneling Protocol
QoS | quality of service
R&D | research and development
RA | route aggregation
RADIUS | remote access dial-in user service
RBD | reliability block diagram
RC | rate critical
RED | random early detect
RF | route filter
RFC | request for comments
RFI | request for information
RFP | request for proposal
RFQ | request for quote
RIP | Routing Information Protocol
RMA | reliability, maintainability, and availability
RMON | remote monitoring
RO | read only
RPV | remotely piloted vehicle
RSA | Rivest-Shamir-Adleman
RSVP | Resource Reservation Protocol
RT | real-time
RW | read/write
s | seconds
SA | systems administrator
SAN | storage area network
SAR | segmentation and reassembly
SCM | supply chain management
SCSI | small computer system interface
SDR | sustained data rate
SHA | secure hash algorithm
SIP | Session Initiation Protocol
SLA | service-level agreement
SLAPM | SLA performance metrics
SMDS | switched multimegabit data service
SMON | switch monitoring
SMS | special multicast server, subscriber management system
SNMP | Simple Network Management Protocol
SOH | section overhead
SONET | synchronous optical network
SPE | SONET payload envelope
SSH | secure shell
SSL | secure sockets library
ST | stochastic
SW or S/W | software
TCP | Transmission Control Protocol
T&I | test and integration
TFTP | Trivial File Transfer Protocol
ToS | type of service
UBR | unspecified bit rate
UI | user interface
UID | user ID
UPS | uninterruptible power supply
USM | user-based security model
VBR | variable bit rate
VLAN | virtual LAN
VLSM | variable-length subnet mask
VoIP | voice over IP
VPN | virtual private network
VRML | Virtual Reality Markup Language
WAN | wide area network
WDM | wavelength division multiplexing
WFQ | weighted fair queuing
WG | workgroup
WRED | weighted random early detect
xSP | (various) service provider


Index

A

AAAA, 372
access/distribution/core architectural model, 232
access regions, 217
accounting management, 310
acronyms, 477–489
adaptability, 61, 392, 400
adding hierarchy, 8, 9
adding interconnectivity, 8, 10
adding routing, 8
address/class calculations, 250
address identifier, 249
address mask, 249
address prefix, 266
address resolution protocol (ARP), 394
address terms/meanings, 252
addressing, 248
addressing fundamentals, 249–251
addressing mechanisms, 255–268
addressing/routing architecture, 219–220, 246–295
addressing fundamentals, 249–251
addressing mechanisms, 255–268
addressing strategies, 277–280
architectural considerations, 290–292
classful addressing, 255–257
external relationships, 290–292
internal relationships, 290
private addressing and NAT, 267–268
reference books, 248
routing boundaries, 269–271
routing flows, 268–269, 272–277
routing fundamentals, 251–254
routing mechanisms, 268–277
routing protocols, 282–290
routing strategies, 280–290
subnetting, 258–260
supernetting, 262–267
variable-length subnetting, 260–262
addressing strategies, 277–280
admission control, 341, 342
AF, 337
affordability, 61
AH, 367
airline industry, 43
alarm, 309
application behavior, 112
application groups, 68–70
application locations, 70–71
application requirements, 62–71
application types, 62–68
applications map, 71
Archie, 65
architectural models, 229–243
example (applying the models), 241–243
flow-based models, 233–235
functional models, 235–237
topological models, 231–232
using, 237–240
architecture. See network architecture
architecture/design defensibility, 15–16
archival/local storage for management data, 318, 319
ARP, 394
Art of Systems Architecting, The (Maier/Rechtin), 54
AS, 269
assured forwarding (AF), 337
asymmetric flows, 401
asynchronous applications, 66
ATM and SONET Basics (Dobrowski/Grise), 2, 386
ATM Solutions for Enterprise Internetworking (Ginsburg), 425
ATM-specific API, 24, 25
ATM switching, 434–443
audit trail, 15–16
authentication header (AH), 367
auto-switch-over redundancy, 452
autonomous system (AS), 269, 395
availability, 43, 63, 114–121


Index_B

Team LiB

Index

B

backbone flows, 405
bandwidth, 41
best-effort applications, 64
best-effort networks, 34, 35
best-effort service, 33
best-effort service offerings, 37
best-effort service requests, 37
BGP, 285
BGPv4, 285
bidirectional flow, 161
black-box method, 418–420
book, overview, 3
broadcast domain, 416
broadcast technologies, 394
bulk data transport applications, 70
business management, 299


Index_C

Team LiB

Index

C

call admission control (CAC), 35
campus requirements map, 146
capacity, 41–42, 64
capacity plan, 195
capacity planning, 3, 389, 393, 405
capacity requirements, 126–129
capacity upgrades, 404, 405
casualty procedures, 136, 137
CBQ, 345
CDN, 8
centralized management, 313, 324
CERT(R) Guide to System and Network Security Practices, The (Allen), 210
characterization of user behavior, 111
characterizing behavior, 108–112
checks and balances, 317
choosing technology. See Selecting technology for network design
CIDR, 265
CIDR block, 266
CIR, 336
class A address, 255, 256
class B address, 255, 256
class C address, 255, 256
class D address, 257
class E address, 257
class-based queuing (CBQ), 345
classful addressing, 255–257
classification, 342
classless interdomain routing (CIDR), 265
client-server applications, 70
client-server architectural model, 233–234
client-server flow model, 180–182
climate-modeling problem, 185
CMIP/CMOT, 302
cold spares, 451
complexity, 11–15
component architectures, 214–225
addressing/routing architecture, 219–220
network management architecture, 221–222
optimizing, 224–225
performance architecture, 222–223
security architecture, 223–224
See also specific architectures
component requirements, 30
composite flows, 161, 162, 389
Computer Security Handbook (Bosworth/Kabay), 358
computing cluster, 187
confidence, 138–140
configuration, 308
configuration management, 310
configuration mechanisms, 308–309
conformance subset of the MIB, 320
conforming traffic, 342
connection establishment, 399
connection support, 396–399
constraints, 216, 324
content delivery network (CDN), 8
core regions, 217
core requirements, 55
CoS, 336
cost/performance graph, 390
critical flows, 163
CT scanners, 74
customer expectations, 17–18, 100


Index_D

Team LiB

Index

D

data flows, 158. See also flow analysis
data migration, 320
data rates, 126–129
data sink, 171–177
data sources, 171–177
David Linthicum's Guide to Client/Server and Intranet Development (Linthicum), 158
default route, 253, 272
default route propagation, 220, 272
definitions (glossary), 459–477
delay, 42, 64–65
delay requirements, 121–126
delay variation, 42, 125–126
demilitarized zone (DMZ), 217, 271
dependencies, 216, 323
design goals, 387–391
Designing Quality of Service Solutions for the Enterprise (Siegel), 210, 332
device components, 76
device locations, 76–78
device requirements, 71–78
device types, 72–74
differentiated services (DS), 336–340
differentiated services code points (DSCPs), 336
DiffServ, 336–340
DiffServ edge devices, 351
directionality, 177
distance limitations, 402
distance-vector routing algorithm, 283
distributed-computing applications, 69
distributed-computing flow model, 186–189
distributed-computing flows with a switch applied, 433
distributed management, 313–314, 324
distribution regions, 217
DMZ, 217, 271
documentation, supportability, 136
downstream, 161
downstream/upstream directions, 346, 347
downtime, 115
dropping, 343
DS, 336–340
DSCPs, 336
dynamic NAT, 268, 371


Index_E

Team LiB

Index

E

eBGP, 285
EF, 337
EGP, 270
80/20 rule
life cycle costs, 46
network traffic, 2
element management, 299
encapsulating security payload (ESP), 367
encryption/decryption, 369–371
end devices, 72
end-to-end architectural model, 236–237
end-to-end characteristics, 301
end-to-end delay, 42, 124
enterprise requirements, 85
enterprise SLA, 347
Enterprise System Architectures: Building Client Server and Web Based Systems (Goodyear), 54
environment-specific thresholds, 113, 120, 140–142
error/loss rate, 120–121, 139
ESP, 367
Essentials of ATM Networks and Services (Ibe), 2, 386
Ethereal, 102
Etherpeak, 102
event, 304
event notification, 304–305
existing networks and migration, 78–80
expedited forwarding (EF), 337
exterior gateway protocol (EGP), 270
external BGP (eBGP), 285
external interfaces, 217
external relationships
addressing/routing architecture, 290–292
network management architecture, 325–326
performance architecture, 352–353
reference architecture, 227–228
security and privacy architecture, 379–380


Index_F

Team LiB

Index

F

FA, 268
failure modes, effects, and critically analysis (FMECA), 134
Fast Ethernet (FE), 29–30
fault management, 309
FCAPS model, 309–310
FE, 29–30
features, 55
FIFO, 345
file transfer, 64
financial requirements, 84–85
firewalls, 372
Firewalls and Internet Security (Cheswick/Bellovin), 358
first-generation networks, 11
first in first out (FIFO), 345
five nines, 114
flow aggregation point, 169
flow analysis, 156–207
composite flow, 161
critical flow, 163
data sources/sinks, 171–177
example, 195–202
flow map, 200, 202
flow models, 177–189
flow prioritization, 189–191
flow specification (flowspec), 191–195
flows, 158–163
identifying/developing flows, 164–171
individual flow, 161
profile, 169–170
purpose, 205
reference books, 158
top N applications, 170–171
flow-based architectural models, 233–235
flow characteristics, 160
flow considerations, 405
flow map, 200, 202
flow models, 177–189
client-server, 180–182
distributed computing, 186–189
hierarchical client-server, 182–186
peer-to-peer, 178–180
flow prioritization, 189–191
flow specification (flowspec), 191–195
flows, 158–163
flowspec algorithm, 192–195
FMECA, 134
fourth-generation networks, 12
Frame Relay: Technology and Practice (Buckwalter), 2, 386
FTP, 68
functional architectural models, 235–237
functional area (FA), 268
functionality, 61
functions, 31, 214, 216
funding, 191
future growth, 62
future requirements, 55


Index_G

Team LiB

Index

G

gathering/listing requirements, 96–104
general-access, 22
general threshold, 113, 120
generations of networking, 12
generic components of a system, 20
generic computing devices, 72, 73
generic system with interfaces added, 23
global addresses, 251, 252
glossary of acronyms, 477–489
glossary of terms, 459–477
Gopher, 64
group, 395
group size, 395–396
guaranteed performance requirements, 144–145
guaranteed service, 33
guaranteed service offerings, 38


Index_H

Team LiB

Index

H

Hacking Exposed: Network Security Secrets & Solutions (McClure et al.), 358
hard boundary, 270
hard state, 396
hierarchical client-server architectural model, 234
hierarchical client-server flow model, 182–186
hierarchical management, 314–315, 324
hierarchy, 7–8, 12–13, 449–450, 454
hierarchy added to a network, 8, 9
high performance, 36
high-redundancy path, 452–453
High-Speed Networking: A Systematic Approach to High-Bandwidth Low-Latency Communication (Sterbenz/Touch), 332
hot-standby path, 452
human response time (HRT), 122
hybrid mechanisms, 445–448
MPOA, 446–447
NHRP, 445–446
service switching, 447–448


Index_I

Team LiB

Index

I

IBGP, 285
ICDs, 231
IGP, 270
iLAN, 271
in-band management, 310–312, 323–324
individual flow, 161
Information Security Architecture: An Integrated Approach to Security in the Organization (Tudor), 358
information sources. See Sources of information
informational requirements, 55
initial architecture/design goals, 97
initial conditions, 96–100, 147
Inside Network Perimeter Security: The Definitive Guide to Firewalls, Virtual Private Networks (VPNs), Routers, and Intrusion Detection Systems (Northcutt et al.), 358
instrumentation, 306
instrumentation mechanisms, 306–308
INTD, 121–122
integrated services (IS), 336–340
integration into OSS, 321
interaction delay (INTD), 121–122
interactions
addressing/routing and network management, 291, 325
addressing/routing and performance, 229, 291, 352
addressing/routing and security, 291–292, 379
encryption/decryption and other security mechanisms, 379
network management and performance, 229, 325–326, 352
network management and security, 229, 326, 379
network management architecture, 322–324
performance and security, 228, 352–353, 379–380
interactive applications, 63, 67–68
interactive bulk applications, 68
interactive burst applications, 67–68
interactivity, 60
Interconnection: Bridges, Routers, Switches, and Internetworking Protocols (Perlman), 425
interconnection mechanisms, 426–428
interconnection strategies, 424–457
applying interconnection mechanisms to design, 449
ATM switching, 434–443
background, 426–428
example (protocol overhead analysis), 436–439
hierarchy, 449–450
hybrid mechanisms, 445–448
LANE, 439–441
MPOA, 446–447
NHRP, 445–446
redundancy, 450–453
reference books, 425–426
routing, 443–445
service switching, 447–448
shared medium (no interconnection), 429–431
switching, 431–443
Interconnections: Bridges, Routers, Switches, and Interconnecting Protocols (Perlman), 386
interconnectivity, 7–8, 12–13
interconnectivity added to a network, 8, 10
interface control descriptions (ICDs), 231
interior gateway protocol (IGP), 270
internal BGP (IBGP), 285
internal relationships, 214
addressing/routing architecture, 290
network management architecture, 322–324
performance architecture, 352
security and privacy architecture, 378–379
Internet QoS: Architectures and Mechanisms for Quality of Service (Wang), 210, 332
interoperability, 281
interoperability dependencies, 80
intranet, 445
intranet/extranet architectural model, 235, 236
Introduction to Distributed and Parallel Computing, An (Crichlow), 158
IntServ, 337–340
IP addresses, 249–251
IP QoS, 336
IPSec, 367
IS, 336–340
isolating areas (black-box method), 418–420
isolation LAN (iLAN), 271


Index_J

Team LiB

Index

J

jitter, 42


Index_K

Team LiB

Index

K

knowledge element (postimplementation phase), 46


Index_L

Team LiB

Index

L

LAN emulation (LANE), 439–441
LAN/MAN/WAN architectural model, 231
LANE, 439–441
last foot problem, 72
last mile problem, 72
latency, 42
limit, 39–40
line rate, 41
link-layer addresses, 251
link-state routing algorithm, 283
local addresses, 251, 252
local/archival storage for management data, 318, 319
location
application, 70–71
device, 76–78
mapping, 104
location dependencies, 79
logical IP subnet (LIS), 441
loss rate, 120–121, 139
low performance, 36
low-redundancy path, 450–451


Index_M

Team LiB

Index

M

maintainability, 43, 63, 113
maintenance element (postimplementation phase), 46
maintenance procedures, 136
maintenance support concept, 138
management information base (MIB), 106, 302, 320
management of network management data, 318–320
management traffic rate, 316
map/mapping
applications map, 71
flow map, 200, 202
location information, 104
requirements map, 58, 59, 145–146
marking, 342
may/optional, 56
mean-time-to-repair (MTTR), 43
measures/measurement
performance measures, 102
service metrics, 107
uptime, 116–119
mechanisms, 214
medium-redundancy path, 451–452
metadata, 320
metering, 342
Methodology for Client/Server and Web Application Development, A (Fournier), 158
metropolitan-area map, 105
MIB, 106
MIB-II, 302, 320
MIB selection, 320–321
mission-critical applications, 63, 64
mobile IP, 220
mobility, 61
modeling, 109
monitoring, 81, 302
monitoring for event notification, 304–305
monitoring for trend analysis and planning, 305–306
monitoring mechanisms, 302–306
Mosaic, 65
MPLS, 336
MPLS: Technology and Applications (Davie/Rekhter), 426
MPOA, 446–447
MTBCF, 113
MTBF, 113
MTTR, 43, 113
multicasts, 220
multipart flowspec, 192, 194
multiple requirements maps, 145
multiple-tier performance, 36
multiprotocol label switching (MPLS), 336
multiprotocol over ATM (MPOA), 446–447
multitier performance networks, 99
must not/shall not, 56
must/shall/required, 56


Index_N

Team LiB

Index

N

NAPT, 268, 371
NAT, 276–278, 292, 371–372
native ATM network, 23, 24
native broadcast support, 394–396
natural mask, 31, 32
NBMA technologies, 394–399
network, system, and support service dependencies, 80
network address, 249–251
network address port translation (NAPT), 268, 371
network address translation (NAT), 276–278, 292, 371–372
network analysis, 4–5
network architecture, 5, 6, 208–245
architectural models, 229–243. See also architectural models
architecture/design, contrasted, 211–213
component architectures, 214–225. See also component architectures
reference architecture, 225–229
reference books, 210
systems architecture, 243
what is it, 243–244
network design, 6, 211–213, 386
network device, 301
network-element management, 299
network environment, 5
network file server (NFS), 398
network management, 221, 298–301
network management and security, 80–83
network management architecture, 221–222, 296–329
architectural considerations, 309–326
areas to be addressed, 298
centralized management, 313
chicks and balances, 317
configuration mechanisms, 308–309
distributed management, 313–314
external relationships, 325–326
FCAPS mode, 309–310
hierarchical management, 314–315
in-band/out-of-band management, 310–312
instrumentation mechanisms, 306–308
integration into OSS, 321
internal relationships, 322–324
management of network management data, 318–320
MIB selection, 320–321
monitoring mechanisms, 302–306
network devices/characteristics, 301
network management, defined, 299–301
network management mechanisms, 302–309
reference books, 297–298
scaling network management traffic, 316–317
network management data, 318–320
network management mechanisms, 302–309
network management protocol, 302
network management requirements, 81–82
network management tasks, 80–81
network obsolescence, 80
network perimeter security, 371–372
network privacy, 358. See also security and privacy architecture
network propagation delay, 122
network requirements, 9, 78–83
network security, 358. See also security and privacy architecture
network services, 25–26
network supportability, 45–47
network/system complexity, 11–15
network uptime, 114–121
next generation capabilities, 12
next-hop resolution protocol (NHRP), 445–446
next-hop router, 254
NFS, 398
NHRP, 445–446
99.999% uptime requirement, 119
non-real time applications, 66
nonbroadcast multiple-access (NBMA) technologies, 394–399
nonconforming traffic, 342–343
northbound interface, 321


Index_O

Team LiB

Index

O

OAM&P applications, 70
OC level, 403
one-part flowspec, 192, 194
open system interconnect (OSI), 20, 21
operational availability, 43, 114
operational suitability, 130–133
operations, administration, maintenance and provisioning (OAM&P) applications, 70
operations element (postimplementation phase), 46
optical carrier (OC) level, 403
OSI, 20, 21
OSPF, 284–285
out-of-band management, 310–312, 323–324
overview of book, 3


Index_P

Team LiB

Index

P

PADI, 373
PADO, 373
PADR, 373
PADS, 373
parallel computing, 188
path diversity, 450
pathchar, 107
PDPs, 351
Peer-to-Peer: Building Secure, Scalable, and Manageable Networks (Hebeler/Moore), 158
peer-to-peer architectural model, 233
peer-to-peer flow model, 178–180
peering, 220
PEP, 351
per-element characteristics, 301
per-flow funding, 191
per-link characteristics, 301
performance, 222, 332
performance architecture, 222–223, 330–355
architectural considerations, 350–353
background, 332–333
developing goals for performance, 333–336
evaluation of performance mechanisms, 350–351
external relationships, 352–353
internal relationships, 352
performance mechanisms, 336–350
policies, 348–350
prioritization, 340–341
QoS, 336–340
queuing, 344–346
reference books, 332
scheduling, 344
SLAs, 346–348
traffic management, 341–344
performance characteristics, 41–45
capacity, 41–42
delay, 42
devices, 74–76
performance envelopes, 44–45
RMA, 42–44
performance constraints, 79
performance envelope, 44–45
performance envelope with generic thresholds, 129
performance limits, 40
performance management, 310
performance measurements, 102
performance mechanisms, 336–350
performance mechanisms with policies added, 349
performance mechanisms with SLAs added, 349
performance profile, 169–170
performance thresholds, 40
performance upgrade paths, 402–405
persistent addresses, 251, 252
physical security, 366–367
ping, 42, 107, 124, 140, 304
ping loss rate, 140
PKI, 370–371
planned hierarchy, 430
Point-to-Point Protocol (PPP), 373
policies, 11, 273, 348–350
policy decision points (PDPs), 351
policy enforcement points (PEPs), 351
polling intervals, 304
postimplementation costs, 46
postimplementation phases of network life cycle, 46
PPP, 373
PPP over Ethernet (PPPoE), 373
PPPoE active discovery initiation (PADI), 373
PPPoE active discovery offer (PADO), 373
PPPoE active discovery request (PADR), 373
PPPoE active discovery session (PADS), 373
predictable performance requirements, 143–144
predictable service offerings, 38
predictable services, 33
presentation quality, 60
primary storage, 303
prioritization, 340–341
prioritizing flows, 189–191
priority levels, 341
privacy, 223. See also security and privacy architecture
private addresses, 252
private IP address, 251, 267
process of requirements analysis. See requirements analysis, process
profile, 169–170
protocol and application security, 367–369
protocol overhead analysis, 436–439
public addresses, 252
public IP addresses, 251
public key infrastructure (PKI), 370–371


Index_Q

Team LiB

Index

Q

QoS, 336–340
quality of service, 11
quality of service (QoS), 336–340
queuing, 344–346
queuing mechanisms, 345–346
Queuing Systems Theory (Kleinrock), 332


Index_R

Team LiB

Index

R

RADIUS, 373
random early detect (RED), 346
rate-critical applications, 63, 64
RBD, 134, 135
readily available, 451
real-time, 65
real-time analysis, 304
real-time applications, 65–66
real-time telemetry stream, 38
RED, 346
red flags, 101–102
redundancy, 114, 392, 450–453, 454
reference architecture, 225–229
reference books. See Sources of information
reference network architecture, 5
regions, 217
rejected requirements, 55
reliability, 42–43, 60, 113
reliability block diagram (RBD), 134, 135
remote access, 372
remote access dial-in user service (RADIUS), 373
remote access security, 372–375
repair and spare parts, 137–138
repairing system failure, 113
requirements, 30, 31, 54
requirements analysis, 52–155
application requirements, 62–71
device requirements, 71–78
enterprise requirements, 85
financial requirements, 84–85
key words/phrases, 56
network requirements, 78–83
process, 94–155. See also Requirements analysis, process
reference books, 54
requirements map, 89
requirements specification, 85–88
supplemental performance requirements, 83–84
user requirements, 58–62
why needed, 56
requirements analysis, process, 94–155. See also requirements analysis
capacity requirements, 126–129
characterizing behavior, 108–112
customer expectations, 100
delay requirements, 121–126
environmental-specific thresholds, 140–142
gathering/listing requirements, 96–104
initial conditions, 96–100
mapping location information, 104
performance measurements, 102
predictable/guaranteed performance, 143–145
requirements mapping, 145–146
requirements specification, 146–148
RMA requirements, 113–121
service metrics, 105–108
supplemental performance requirements, 129–140
tracking/managing requirements, 103–104
working with users, 100–102
Requirements Engineering: A Good Practice Guide (Sommerville et al.), 54
requirements map, 58, 89
requirements mapping, 145–146
requirements specification, 57, 85–88, 146–148
requirements tracking/management, 87, 103–104
resource control, 222
resource reservation protocol (RSVP), 337
RFC, 23
RFC 1918, 267
RFC 2119, 56
RFC 2225, 441
RFC 2474, 332
RFC 2475, 332
RFC 2863, 321
RFC 3261, 342
RIP, 283
RIPv2, 283
risk analysis, 82
RMA, 42–44, 63–64, 133–134
RMA improvement, 404
RMA requirements, 113–121
round-trip delay, 42, 124
route aggregation, 273
route filter, 272
route filtering, 272
route-manipulation techniques, 272–277
routing, 248, 443–445
routing boundaries, 269–271
routing evolution, 14
routing flows, 268–269, 271, 272–277
routing fundamentals, 251–254
Routing in the Internet (Huitema), 210
routing management domains, 269
routing mechanisms, 268–277
routing policies, 220
routing protocols, 252, 270, 281–290
routing strategies, 280–290
RSVP, 337


Index_S

Team LiB

Index

S

scaling dependencies, 79
scaling network management traffic, 316–317
scheduling, 344
scientific visualization, 185
second-generation networks, 11
secondary storage, 303
secure sockets library (SSL), 371
security, 61, 223
security and privacy architecture, 223–224, 356–383
architectural considerations, 375–380
assets to be protected, 361
classic security considerations, 358
developing a plan, 359–360
encryption/decryption, 369–371
evaluation of security mechanisms, 375–378
external relationships, 379–380
internal relationships, 378–379
network perimeter security, 371–372
physical security, 366–367
policies/procedures, 363–365
protocol and application security, 367–369
reference books, 358
remote access security, 372–375
security and privacy mechanisms, 365–375
security awareness, 367
security zones, 376–378
threat analysis, 360–363
security and privacy mechanisms, 365–375
security awareness, 367
security domains, 270
security from natural disasters, 366–367
security management, 310
security perimeters, 376
security policies and procedures, 363–365
security requirements, 82–83
security task assessment, 82
security zones, 376–378
segmenting the network, 413–418
selecting technology for network design, 384–423
applying evaluation criteria/guidelines, 420
background, 386–387
broadcast/NBMA technologies, 394–399
design goals, 387–391
flow considerations, 405–406
guidelines/constraints on technology evaluations, 406–412
isolating areas (black-box method), 418–420
making the technology choices, 412–420
reference books, 386
segmenting the network, 413–418
technology evaluation, 392–412
technology functions/features, 400–402
selective copying of data, 318–319
server-to-manager flows, 183
server-to-server flows, 183
servers, 73
service characteristics, 26–40
service levels, 28–30
service metrics, 39–40
service offerings, 37–39
service requests and requirements, 33–37
system components and network services, 30–33
service description, 25–26
service-level agreements (SLAs), 11, 346–348
service levels, 28–30
service management, 299
service metrics, 39–40, 105–108
service offering, 27
service offerings, 37–39
service plan, 195
service planning, 389, 406
service-provider architectural model, 235, 236
service request, 27
service requests and requirements, 33–37
service requirements, 30
service switching, 447–448
services, 25
session, 397
shaping, 342–343
shared, multiprocessor computing network, 128
shared-medium mechanism, 429–431
should not/not recommended, 56
should/recommended, 56
Simple Network Management Protocol (SNMP) (Case et al.), 210, 298
simulation, 109
simulation of network performance behavior, 110
single-tier/multitier performance architectural model, 235–236
single-tier performance networks, 99
single-tier performance requirements, 36
sizing the network design, 413–418
SLAs, 11, 346–348
SMDS, 17
Sniffer, 102
SNMP, 302
SNMP, SNMPv2, SNMPv3, and RMON 1 and 2 (Stallings), 297
SNMP security, 369
SNMP version 3 (SNMPv3), 302
soft boundary, 271
soft state, 396
SONET (Goralski), 426
SONET OC levels, 403
sources of information
addressing/routing architecture, 248
basics, 2
flow analysis, 158
interconnection strategies, 425–426
network architecture, 210
network management architecture, 297–298
performance architecture, 332
requirements analysis, 54
security and privacy architecture, 358
selecting technologies, 386
spare and repair parts, 137–138
specialized devices, 74, 75
specification
flow, 191–195
requirements, 57, 85–88, 146–148
SSL, 371
state, 396
stateful, 396
stateless, 396
static NAT, 268, 371
static routes, 282
storage archives, 303
stub network, 282
subnet, 258
subnet mask, 258, 259
subnetting, 258–260
Successful SAP R/3 Implementation: Practical Management of ERP Projects (Welti), 158
supernet mask, 264
supernetting, 262–267
supplemental performance requirements, 83–84, 129–140
support concept, 138
supportability, 45–47, 61, 133–138, 392
Switch Book: The Complete Guide to LAN Switching Technology, The (Seifert), 426
Switched, Fast, and Gigabit Ethernet (Riley/Breyer), 2, 386, 426
switched multimegabit data service (SMDS), 17
switching, 431–443
system, 20
system and component technical documentation, 136
system components and network services, 30–33
system description, 20–25
system OAM&P applications, 70
system state, 398
system with ATM in network, 23, 24
systems architecture, 243
Systems Engineering: Coping with Complexity (Arnold et al.), 54
systems methodology, 19


Index_T

Team LiB

Index

T

TCP/IP Illustrated (Stevens), 2
TCPdump, 107
technical documentation, 136
technology selection. See Selecting technology for network design
telemetry/command and control applications, 69
telephony network, 35
tele*service applications, 70
templates
device descriptions, 73
FMECA data, 135
initial conditions, 147
questionnaire, 149
requirements specification, 86
temporary addresses, 251, 252
tertiary storage, 303
testbed network, 102, 103
third-generation networks, 11, 12
threat analysis, 360–363
three-tier maintenance structure, 139
3D performance envelope, 45
threshold, 39–40
defined, 39
environment-specific, 113, 120, 140–142
general, 113, 120
throughput, 41
throughput estimates, 410
timeliness, 60
top N applications, 170–171
topological models, 231–232
ToS, 336
traceroute, 107
tracking/managing requirements, 103–104
trade-offs, 215–216, 323–324
traditional view of system, 22
traffic conditioning, 341, 342
traffic flows, 9, 12, 158. See also flow analysis
traffic management, 341–344
traffic metering, 343
traffic variables, 316
transport mode (IPSec), 367
trap, 302
trend analysis, 305
tunnel mode (IPSec), 368
tunneling, 368
two-part flowspec, 192, 194
2D performance envelope, 44
typical-usage scenarios, 177


Index_U

Team LiB

Index

U

Understanding SNMP MIBs (Perkins/McGinnis), 298
upgrade paths, 402–405
upstream, 161
upstream/downstream directions, 346, 347
uptime, 114–121
user behavior, 110–112
user requirements, 30, 58–62


Index_V

Team LiB

Index

V

value-added services, 402
variable-length subnetting, 260–262, 278, 279
virtual private network (VPN), 368, 374
virtual user groups, 415
visualization applications, 69
VLANs, 220
VPN, 368, 374


Index_W

Team LiB

Index

W

warning signals, 101–102
web development, access, and use applications, 69–70
weighted fair queuing (WFQ), 345
weighted RED (WRED), 346
WFQ, 345
WG, 268
wireless networks, 400
workgroup (WG), 268
working with users, 100–102
worst-case scenarios, 176
WRED, 346


List of Figures

Chapter 1: Introduction

Figure 1.1: Information flows between network analysis, architecture, and design.
Figure 1.2: Inputs and outputs to network analysis process.
Figure 1.3: Inputs and outputs to network architecture process.
Figure 1.4: Hierarchy and interconnectivity in a network.
Figure 1.5: Hierarchy added to a network.
Figure 1.6: Interconnectivity added to a network.
Figure 1.7: Generations of networking.
Figure 1.8: Hierarchy and traffic flow.
Figure 1.9: Interconnectivity added to optimize traffic flow.
Figure 1.10: Routing evolution.
Figure 1.11: Generic components of a system.
Figure 1.12: Comparison of OSI layers to system levels.
Figure 1.13: Device component separated into constituents.
Figure 1.14: Traditional view of system.
Figure 1.15: Generic system with interfaces added.
Figure 1.16: Example of system with ATM in network.
Figure 1.17: Example of system with native ATM.
Figure 1.18: Grouping characteristics into service levels and descriptions.
Figure 1.19: Various demarcation points for end-to-end in a network.
Figure 1.20: Example of service hierarchy within a network.
Figure 1.21: Service requests, offerings, and metrics.
Figure 1.22: Requirements flow down components to network.
Figure 1.23: Capacity at each point in transmission path before security firewall.
Figure 1.24: Capacity at each point in transmission path after security firewall.
Figure 1.25: Performance of Fast Ethernet connection under best-effort conditions.
Figure 1.26: Performance of Fast Ethernet connection under CAC.
Figure 1.27: Performance limits and thresholds.
Figure 1.28: Example of a 2D performance envelope.
Figure 1.29: Example of a 3D performance envelope.
Figure 1.30: Network hierarchy for Exercise 2.

Chapter 2: Requirements Analysis: Concepts

Figure 2.1: Requirements are separated into core/fundamental requirements, features, future requirements, and rejected and informational requirements.
Figure 2.2: Types of user requirements.
Figure 2.3: Requirements become more technical as we move closer to network devices.
Figure 2.4: Types of application requirements.
Figure 2.5: Delay types.
Figure 2.6: Example applications map.
Figure 2.7: Types of device requirements.
Figure 2.8: Example template for device descriptions.
Figure 2.9: Specialized devices.
Figure 2.10: Device components.
Figure 2.11: Device locations.
Figure 2.12: Types of network requirements.
Figure 2.13: Security risk assessment.
Figure 2.14: Template for the requirements specification.
Figure 2.15: Beginning of requirements specification for Example 2.1.
Figure 2.16: Beginning of requirements map for Example 2.1.
Figure 2.17: Template for Exercise 9.

Chapter 3: Requirements Analysis: Process

Figure 3.1: Requirements analysis process.
Figure 3.2: Determining performance targets— single or multitier performance.
Figure 3.3: Measuring performance using a testbed and the existing network.
Figure 3.4: Requirements tracking and management in tabular form.
Figure 3.5: Example of a metropolitan-area map.
Figure 3.6: Using ping and IP packet loss as service metrics for RMA.
Figure 3.7: Example service metrics.
Figure 3.8: Simulation of network performance behavior.
Figure 3.9: Characterization of user behavior.
Figure 3.10: Uptime measured over different time periods.
Figure 3.11: Uptime measured everywhere.
Figure 3.12: Uptime measured selectively.
Figure 3.13: Thresholds between testbed and low-and high-performance uptime.
Figure 3.14: Delay estimates for user requirements.
Figure 3.15: Performance regions for interactive-burst and interactive-bulk applications.
Figure 3.16: Completion times and data sizes for selected applications.
Figure 3.17: Example of a shared, multiprocessor computing network.
Figure 3.18: Performance envelope with generic thresholds.
Figure 3.19: Elements of operations and support.
Figure 3.20: Sample reliability block diagram.
Figure 3.21: Template for FMECA data.
Figure 3.22: Three-tier maintenance structure.
Figure 3.23: Example loss threshold.
Figure 3.24: Plot of capacity requirements with possible thresholds.
Figure 3.25: Plot of capacity requirements with no distinct groupings.
Figure 3.26: Multiple requirements maps.
Figure 3.27: Campus requirements map.
Figure 3.28: Template for initial conditions.
Figure 3.29: Requirements gathered from initial meeting with customer.
Figure 3.30: Template for questionnaire.
Figure 3.31: Additional requirements gathered from questionnaire.
Figure 3.32: Additional requirements gathered from meetings with users and staff.
Figure 3.33: Application performance requirements for Exercise 2.
Figure 3.34: Wireless connections to corporate network using PPP and PPPoE.
Figure 3.35: Diagram of system for Exercise 10.

Chapter 4: Flow Analysis

Figure 4.1: Flow attributes apply end-to-end and throughout network.
Figure 4.2: Common flow characteristics.
Figure 4.3: Flows are represented as unidirectional or bidirectional arrows with performance requirements.
Figure 4.4: Individual flow for a single application with guaranteed requirements.
Figure 4.5: Example composite flows.
Figure 4.6: Flow examples.
Figure 4.7: Process for identifying and developing flows.
Figure 4.8: Map of device locations for a network.
Figure 4.9: Flows estimated between devices for Application 1.
Figure 4.10: Performance information added to central campus flows for Application 1.
Figure 4.11: Central campus flows for Application 1 expanded with Building C.
Figure 4.12: Consolidating flows using a flow aggregation point.
Figure 4.13: A performance profile (P1) applied to multiple flows with the same performance characteristics.
Figure 4.14: A project may incorporate multiple approaches in choosing applications.
Figure 4.15: Convention for data sources and sinks.
Figure 4.16: Example data sources.
Figure 4.17: Example data sinks.
Figure 4.18: Data sources, sinks, and flows added to first part of Application 1.
Figure 4.19: Data sources, sinks, and flows added to Application 2 (two options shown).
Figure 4.20: Data-migration application with server-server flows isolated.
Figure 4.21: Peer-to-peer flow model.
Figure 4.22: Example of peer-to-peer flows in the early Internet.
Figure 4.23: Peer-to-peer flows in a telelearning environment.
Figure 4.24: Client-server flow model.
Figure 4.25: Example of client-server flows.
Figure 4.26: Hierarchical client-server flow model.
Figure 4.27: Web services modeled using hierarchical client-server flow model.
Figure 4.28: Components of a climate-modeling problem.
Figure 4.29: Hierarchical client-server model for scientific visualization.
Figure 4.30: Distributed-computing flow model.
Figure 4.31: Flows for a computing cluster.
Figure 4.32: Flows for parallel computing.
Figure 4.33: Example flow information for prioritization.
Figure 4.34: Flows prioritized by number of users served.
Figure 4.35: Flows prioritized by reliability.
Figure 4.36: Descriptions of flow specifications.
Figure 4.37: One-part flow specification.
Figure 4.38: Two-part flow specification.
Figure 4.39: Multipart flow specification.
Figure 4.40: Building and device locations for example.
Figure 4.41: Map with flow types added.
Figure 4.42: Performance envelope for example.
Figure 4.43: Flow models for flow type 1.
Figure 4.44: Flow model for flow type 2.
Figure 4.45: Flow model for flow type 3.
Figure 4.46: Flow model for flow type 4.
Figure 4.47: Flow map for example.
Figure 4.48: Performance requirements for flows.
Figure 4.49: Performance requirements added to flow map.
Figure 4.50: Two-part flowspec for each flow with performance profile P1.
Figure 4.51: Mainframe environment for OLTP application.
Figure 4.52: Hierarchical client-server environment for OLTP application.

Chapter 5: Network Architecture

Figure 5.1: Comparisons between architecture and design.
Figure 5.2: Architecture and design solutions are multidimensional.
Figure 5.3: Functions, capabilities, and mechanisms.
Figure 5.4: Examples of performance mechanisms in a network.
Figure 5.5: Interactions between performance mechanisms.
Figure 5.6: Component architectures and the reference architecture are derived from network requirements, flows, and goals.
Figure 5.7: Sample chart for listing dependencies between performance mechanisms.
Figure 5.8: Process model for component architecture approach.
Figure 5.9: Component architectures form overlays onto requirements and flow maps.
Figure 5.10: LAN/MAN/WAN architectural model.
Figure 5.11: Access/distribution/core architectural model.
Figure 5.12: Peer-to-peer architectural model.
Figure 5.13: Client-server architectural model.
Figure 5.14: Hierarchical client-server architectural model.
Figure 5.15: Distributed-computing architectural model.
Figure 5.16: Service-provider architectural model.
Figure 5.17: Intranet/extranet architectural model.
Figure 5.18: End-to-end architectural model.
Figure 5.19: Functional and flow-based models complement the topological models.
Figure 5.20: The reference architecture combines component architectures and models.
Figure 5.21: Access/distribution/core model from a flow perspective.
Figure 5.22: Where client-server and hierarchical client-server models may overlap with the access/distribution/core model.
Figure 5.23: Access/distribution/core model with functional and flow-based models added.
Figure 5.24: Flow map from storage example in Chapter 4.
Figure 5.25: Access, distribution, and core areas defined for Example 5.1.
Figure 5.26: Distributed-computing areas defined for Example 5.1.
Figure 5.27: Systems architecture.
Figure 5.28: Network architecture.

Chapter 6: Addressing and Routing Architecture

Figure 6.1: IP Addresses consist of a unique identifier and mask.
Figure 6.2: An IP address in binary and dotted-decimal formats.
Figure 6.3: Address terms and meanings.
Figure 6.4: Traffic is forwarded based on longest (most explicit) address match.
Figure 6.5: Basic tenets of IP forwarding.
Figure 6.6: Classful addressing uses traditional class boundaries to form Class A, B, or C addresses.
Figure 6.7: Masks and sizes for subnetting a Class B network.
Figure 6.8: Modifying the address mask for supernetting.
Figure 6.9: IP address shown with natural mask.
Figure 6.10: IP address shown with supernet mask.
Figure 6.11: Address prefix size determines CIDR block size.
Figure 6.12: Example of workgroups and functional areas.
Figure 6.13: Example of a hard boundary.
Figure 6.14: Example of a soft boundary.
Figure 6.15: Boundaries and routing flows in a network.
Figure 6.16: Policy enforcement between autonomous systems.
Figure 6.17: Example for route-manipulation techniques.
Figure 6.18: Results of route-manipulation techniques applied to AS1.
Figure 6.19: Results of route-manipulation techniques applied to AS2.
Figure 6.20: Applying various addressing strategies.
Figure 6.21: Example for variable-length subnetting.
Figure 6.22: Example with variable-length subnetting applied.
Figure 6.23: Stub networks.
Figure 6.24: Degrees of hierarchy and interconnectivity.
Figure 6.25: Application of internal BGP (iBGP) and external BGP (eBGP).
Figure 6.26: Example application of static routes, IGPs, and EGPs in a network.
Figure 6.27: Iterative evaluation of routing protocols.
Figure 6.28: Example of interactions within addressing/routing architecture.
Figure 6.29: Diagram for Exercises 4 through 7.

Chapter 7: Network Management Architecture

Figure 7.1: Network management hierarchy.
Figure 7.2: Network management is composed of managing elements and transporting management data.
Figure 7.3: Network characteristics can be per element, per link, per network, or end-to-end.
Figure 7.4: Elements of the monitoring process.
Figure 7.5: Monitoring for event notification.
Figure 7.6: Monitoring for metrics and planning.
Figure 7.7: Configuration mechanisms for network management.
Figure 7.8: Traffic flows for in-band management.
Figure 7.9: Traffic flows for out-of-band management.
Figure 7.10: Combination of in-band and out-of-band management traffic flows.
Figure 7.11: Distributed management where each local EMS has its own management domain.
Figure 7.12: Distributed management where monitoring is distributed.
Figure 7.13: Hierarchical management separates management into distinct functions that are distributed across multiple platforms.
Figure 7.14: Scaling network management traffic.
Figure 7.15: Local and archival storage for management data.
Figure 7.16: Selective copying to separate database.
Figure 7.17: Data migration.
Figure 7.18: Integration of network management with OSS.
Figure 7.19: Devices for storage capacity problem.
Figure 7.20: Diagram for Exercises 6 through 10.

Chapter 8: Performance Architecture

Figure 8.1: General mechanisms for performance.
Figure 8.2: Comparison of DiffServ and IntServ.
Figure 8.3: Where DiffServ and IntServ apply in the access/distribution/core model.
Figure 8.4: Illustration of traffic metering at a network device.
Figure 8.5: Traffic conditioning functions.
Figure 8.6: Performance mechanisms act on network devices.
Figure 8.7: Upstream and downstream directions.
Figure 8.8: Upstream and downstream directions for Internet Web traffic.
Figure 8.9: Example of enterprise SLA.
Figure 8.10: Performance mechanisms with SLAs added.
Figure 8.11: Performance mechanisms with policies added.
Figure 8.12: General applications of performance mechanisms.
Figure 8.13: Performance is constrained by security.
Figure 8.14: Network for Exercise 6.

Chapter 9: Security and Privacy Architecture

Figure 9.1: Potential assets and threats to be analyzed.
Figure 9.2: Example of threat analysis worksheet for a specific organization.
Figure 9.3: Example security philosophies.
Figure 9.4: Areas of physical security.
Figure 9.5: Transport mode of IPSec.
Figure 9.6: Tunnel mode of IPSec.
Figure 9.7: Example of packet filtering.
Figure 9.8: Encryption/decryption of network traffic.
Figure 9.9: Remote access mechanisms.
Figure 9.10: Remote access considerations.
Figure 9.11: Process for PPP/PPPoE session establishment.
Figure 9.12: Access/distribution/core architectural model as a starting point for security.
Figure 9.13: Security zones embedded within each other.
Figure 9.14: Developing security zones throughout a network.
Figure 9.15: Security mechanisms may restrict or preclude performance within each zone.
Figure 9.16: Network for Exercises 1 through 3.
Figure 9.17: Network for Exercise 4.

Chapter 10: Selecting Technologies for the Network Design

Figure 10.1: Process for selecting technologies for the network design.
Figure 10.2: Cost/performance graph.
Figure 10.3: Budget allocation for example.
Figure 10.4: Requirements, flows, and network architecture influence design goals.
Figure 10.5: System state.
Figure 10.6: System state as part of network connections.
Figure 10.7: Example of connection establishment.
Figure 10.8: Example of asymmetric flows.
Figure 10.9: Capacity ranges for selected technologies.
Figure 10.10: Overlap in frame relay/SMDS/ATM capacity ranges.
Figure 10.11: Sizing the network design at the (LAN/MAN)/WAN level.
Figure 10.12: Sizing the network design at the campus level.
Figure 10.13: Sizing the network design based on user concentrations.
Figure 10.14: Sizing the network design based on flow hierarchies.
Figure 10.15: Sizing the network design based on functions and features of each area.
Figure 10.16: A black box isolates the inputs and outputs of each area.
Figure 10.17: Black box applied to area under review.
Figure 10.18: Black box applied to areas not under review.
Figure 10.19: Network for Exercise 5.
Figure 10.20: Network for Exercise 6.

Chapter 11: Interconnecting Technologies Within the Network Design

Figure 11.1: Technology selections and network devices need to be interconnected to complete design.
Figure 11.2: Technology selections and network devices when connected.
Figure 11.3: OSI seven-layer model.
Figure 11.4: Interconnecting multiple Ethernet segments using a shared-medium mechanism.
Figure 11.5: Planning hierarchy in the network design.
Figure 11.6: Flows in a distributed-computing model.
Figure 11.7: Distributed-computing flows with a switch applied.
Figure 11.8: Routing distributed-computing flows across a WAN.
Figure 11.9: ATM in a classic IP network.
Figure 11.10: Example of suboptimal flows in classic IP over ATM.
Figure 11.11: Evolution of external interfaces.
Figure 11.12: NHRP flow optimization in an NBMA environment.
Figure 11.13: Using end-to-end or flow information to make forwarding decisions.
Figure 11.14: Summary of evaluation criteria for interconnection mechanisms.
Figure 11.15: Degrees of hierarchy.
Figure 11.16: Low-redundancy path.
Figure 11.17: Medium-redundancy path.
Figure 11.18: High-redundancy path.
Figure 11.19: Guidelines for hierarchy and redundancy.
Figure 11.20: LANE and RFC 2225 networks for Exercise 3.


List of Tables

Chapter 10: Selecting Technologies for the Network Design

Table 10.1: Throughput Estimates for Selected Technologies
Table 10.2: Prioritized Flows and Candidate Technologies


List of Examples

Chapter 1: Introduction

Example 1.1
Example 1.2
Example 1.3
Example 1.4
Example 1.5
Example 1.6
Example 1.7
Example 1.8

Chapter 2: Requirements Analysis: Concepts

Example 2.1: Requirements Analysis for a Company LAN

Chapter 3: Requirements Analysis: Process

Example 3.1: A requirement for upgrades to network equipment is shown.

Chapter 4: Flow Analysis

Example 4.1: Data Migration
Example 4.2: Data Sources and Sinks for Data Migration Applications.

Chapter 5: Network Architecture

Example 5.1: Applying Architectural Models

Chapter 6: Addressing and Routing Architecture

Example 6.1: Address and Class Calculations
Example 6.2: Determining Class and Natural Mask
Example 6.3: Creating Subnets

Chapter 11: Interconnecting Technologies Within the Network Design

Example 11.1: Protocol Overhead Analysis

Team LiB
Previous Section